Fossil SCM

Hoist the "Compatiblity Concerns" section of js-policy.md into javascript.md. Another near-total rewrite, maintaining the original's points.

wyoung 2020-08-19 23:07 UTC js-policy-doc
Commit 7eef486cf4a80fc61ee8ce95a148d8a661e77a92b9fe6726957c3a688fd16f32
1 file changed +27 -6
--- www/javascript.md
+++ www/javascript.md
@@ -9,11 +9,11 @@
99
enhancement to provided functionality, and there is always another way
1010
to accomplish a given end without using JavaScript.
1111
1212
This is not to say that Fossil’s fall-backs for such cases are always as
1313
elegant and functional as a no-JS purist might wish. That is simply
14
-because [the vast majority of web users run with JS enabled](#stats),
14
+because [the vast majority of web users run with JavaScript enabled](#stats),
1515
and a minority of those run with some kind of conditional JavaScript
1616
blocking in place. Fossil’s active developers do not deviate from that
1717
norm enough that we have many no-JS purists among us, so the no-JS case
1818
doesn’t get as much attention as some might want. We do [accept code
1919
contributions][cg], and we are philosophically in favor of graceful
@@ -87,11 +87,11 @@
8787
developers, who in turn are more likely to be power-users, we’d expect
8888
to find Fossil users to be more in favor of some amount of JavaScript
8989
blocking than the average web user. Yet, we’d also expect to find that
9090
our user base has a disproportionately high number who run [powerful
9191
conditional blocking plugins](#block) in their browsers, rather than
92
-block JS entirely. We suspect that between these two forces, the number
92
+block JavaScript entirely. We suspect that between these two forces, the number
9393
of no-JS purists among Fossil’s user base is still a tiny minority.
9494
9595
[s1]: https://blockmetry.com/blog/javascript-disabled
9696
[s2]: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/
9797
[s3]: https://w3techs.com/technologies/overview/client_side_language/all
@@ -127,10 +127,31 @@
127127
Fossil instances or into other web sites.
128128
129129
There is some server-side event logging, but that is done entirely
130130
without JavaScript, so it’s off-topic here.
131131
132
+
133
+## <a id="compat"></a>Compatibility Concerns
134
+
135
+The Fossil project’s developers aim to remain relatively compatible with
136
+the largest portions of the client-side browser base. We use only
137
+standards-defined JavaScript features which are known to work in the
138
+overwhelmingly vast majority of browsers going back approximately 5
139
+years, at minimum, as documented by [Can I Use...?][ciu] We avoid use of
140
+features added to the language more recently or those which are still in
141
+flux in standards committees
142
+
143
+We set this threshold based on the amount of time it typically takes for
144
+new standards to propagate through the installed base.
145
+
146
+As of this writing, this means we are only using features defined in
147
+[ECMAScript 2015][es2015], colloquially called “JavaScript 6.” That is a
148
+sufficiently rich standard that it more than suffices for our purposes.
149
+
150
+[ciu]: https://caniuse.com/
151
+[es2015]: https://ecma-international.org/ecma-262/6.0/
152
+
132153
133154
## <a id="debate"></a>Arguments Against JavaScript & Our Rebuttals
134155
135156
There many common arguments against the use of JavaScript. Rather than
136157
rehash these same arguments on the [forum][ffor], we distill the common
@@ -193,12 +214,12 @@
193214
* ...[open source][flic] and [available][fsrc] to be inspected,
194215
audited, and changed by its users.
195216
196217
* ...compiled directly into the `fossil` binary in a
197218
non-obfuscated form during the build process, so there are no
198
- third-party servers delivering mysterious, obfuscated JS code to
199
- the user.
219
+ third-party servers delivering mysterious, obfuscated JavaScript
220
+ code to the user.
200221
201222
C, Fossil's main implementation language, has been associated with
202223
far more security problems than JavaScript, yet the apparent
203224
alternative to reducing the amount of JavaScript in Fossil is to
204225
increase the amount of C code. Does it not make sense to place as
@@ -284,11 +305,11 @@
284305
command, by clicking around within the web UI, etc.
285306
286307
_Potential Workaround:_ The timeline could be enhanced with `<noscript>`
287308
tags that replace the graph with a column of checkboxes that control
288309
what a series of form submit buttons do when clicked, replicating the
289
-current JS-based features of the graph using client-server round-trips.
310
+current JavaScript-based features of the graph using client-server round-trips.
290311
For example, you could click two of those checkboxes and then a button
291312
labeled “Diff Selected” to replicate the current “click two nodes to
292313
diff them” feature.
293314
294315
[wt]: https://fossil-scm.org/fossil/timeline
@@ -336,11 +357,11 @@
336357
337358
_Graceful Fallback:_ Unlike in the Fossil 2.11 and earlier days, there
338359
is no longer a script-free wiki editor mode. This is not from lack of
339360
desire, only because the person who wrote the new wiki editor didn’t
340361
want to maintain three different editors. (New Ajaxy editor, old
341
-script-free HTML form based editor, and old WYSIWYG JS-based editor.) If
362
+script-free HTML form based editor, and old WYSIWYG JavaScript-based editor.) If
342363
someone wants to implement a `<noscript>` alternative to the new wiki
343364
editor, we will likely accept that [contribution][cg] as long as it
344365
doensn’t interfere with the new editor. (The same goes for adding a
345366
WYSIWYG mode to the new Ajaxy wiki editor.)
346367
347368
--- www/javascript.md
+++ www/javascript.md
@@ -9,11 +9,11 @@
9 enhancement to provided functionality, and there is always another way
10 to accomplish a given end without using JavaScript.
11
12 This is not to say that Fossil’s fall-backs for such cases are always as
13 elegant and functional as a no-JS purist might wish. That is simply
14 because [the vast majority of web users run with JS enabled](#stats),
15 and a minority of those run with some kind of conditional JavaScript
16 blocking in place. Fossil’s active developers do not deviate from that
17 norm enough that we have many no-JS purists among us, so the no-JS case
18 doesn’t get as much attention as some might want. We do [accept code
19 contributions][cg], and we are philosophically in favor of graceful
@@ -87,11 +87,11 @@
87 developers, who in turn are more likely to be power-users, we’d expect
88 to find Fossil users to be more in favor of some amount of JavaScript
89 blocking than the average web user. Yet, we’d also expect to find that
90 our user base has a disproportionately high number who run [powerful
91 conditional blocking plugins](#block) in their browsers, rather than
92 block JS entirely. We suspect that between these two forces, the number
93 of no-JS purists among Fossil’s user base is still a tiny minority.
94
95 [s1]: https://blockmetry.com/blog/javascript-disabled
96 [s2]: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/
97 [s3]: https://w3techs.com/technologies/overview/client_side_language/all
@@ -127,10 +127,31 @@
127 Fossil instances or into other web sites.
128
129 There is some server-side event logging, but that is done entirely
130 without JavaScript, so it’s off-topic here.
131
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
132
133 ## <a id="debate"></a>Arguments Against JavaScript & Our Rebuttals
134
135 There many common arguments against the use of JavaScript. Rather than
136 rehash these same arguments on the [forum][ffor], we distill the common
@@ -193,12 +214,12 @@
193 * ...[open source][flic] and [available][fsrc] to be inspected,
194 audited, and changed by its users.
195
196 * ...compiled directly into the `fossil` binary in a
197 non-obfuscated form during the build process, so there are no
198 third-party servers delivering mysterious, obfuscated JS code to
199 the user.
200
201 C, Fossil's main implementation language, has been associated with
202 far more security problems than JavaScript, yet the apparent
203 alternative to reducing the amount of JavaScript in Fossil is to
204 increase the amount of C code. Does it not make sense to place as
@@ -284,11 +305,11 @@
284 command, by clicking around within the web UI, etc.
285
286 _Potential Workaround:_ The timeline could be enhanced with `<noscript>`
287 tags that replace the graph with a column of checkboxes that control
288 what a series of form submit buttons do when clicked, replicating the
289 current JS-based features of the graph using client-server round-trips.
290 For example, you could click two of those checkboxes and then a button
291 labeled “Diff Selected” to replicate the current “click two nodes to
292 diff them” feature.
293
294 [wt]: https://fossil-scm.org/fossil/timeline
@@ -336,11 +357,11 @@
336
337 _Graceful Fallback:_ Unlike in the Fossil 2.11 and earlier days, there
338 is no longer a script-free wiki editor mode. This is not from lack of
339 desire, only because the person who wrote the new wiki editor didn’t
340 want to maintain three different editors. (New Ajaxy editor, old
341 script-free HTML form based editor, and old WYSIWYG JS-based editor.) If
342 someone wants to implement a `<noscript>` alternative to the new wiki
343 editor, we will likely accept that [contribution][cg] as long as it
344 doensn’t interfere with the new editor. (The same goes for adding a
345 WYSIWYG mode to the new Ajaxy wiki editor.)
346
347
--- www/javascript.md
+++ www/javascript.md
@@ -9,11 +9,11 @@
9 enhancement to provided functionality, and there is always another way
10 to accomplish a given end without using JavaScript.
11
12 This is not to say that Fossil’s fall-backs for such cases are always as
13 elegant and functional as a no-JS purist might wish. That is simply
14 because [the vast majority of web users run with JavaScript enabled](#stats),
15 and a minority of those run with some kind of conditional JavaScript
16 blocking in place. Fossil’s active developers do not deviate from that
17 norm enough that we have many no-JS purists among us, so the no-JS case
18 doesn’t get as much attention as some might want. We do [accept code
19 contributions][cg], and we are philosophically in favor of graceful
@@ -87,11 +87,11 @@
87 developers, who in turn are more likely to be power-users, we’d expect
88 to find Fossil users to be more in favor of some amount of JavaScript
89 blocking than the average web user. Yet, we’d also expect to find that
90 our user base has a disproportionately high number who run [powerful
91 conditional blocking plugins](#block) in their browsers, rather than
92 block JavaScript entirely. We suspect that between these two forces, the number
93 of no-JS purists among Fossil’s user base is still a tiny minority.
94
95 [s1]: https://blockmetry.com/blog/javascript-disabled
96 [s2]: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/
97 [s3]: https://w3techs.com/technologies/overview/client_side_language/all
@@ -127,10 +127,31 @@
127 Fossil instances or into other web sites.
128
129 There is some server-side event logging, but that is done entirely
130 without JavaScript, so it’s off-topic here.
131
132
133 ## <a id="compat"></a>Compatibility Concerns
134
135 The Fossil project’s developers aim to remain relatively compatible with
136 the largest portions of the client-side browser base. We use only
137 standards-defined JavaScript features which are known to work in the
138 overwhelmingly vast majority of browsers going back approximately 5
139 years, at minimum, as documented by [Can I Use...?][ciu] We avoid use of
140 features added to the language more recently or those which are still in
141 flux in standards committees
142
143 We set this threshold based on the amount of time it typically takes for
144 new standards to propagate through the installed base.
145
146 As of this writing, this means we are only using features defined in
147 [ECMAScript 2015][es2015], colloquially called “JavaScript 6.” That is a
148 sufficiently rich standard that it more than suffices for our purposes.
149
150 [ciu]: https://caniuse.com/
151 [es2015]: https://ecma-international.org/ecma-262/6.0/
152
153
154 ## <a id="debate"></a>Arguments Against JavaScript & Our Rebuttals
155
156 There many common arguments against the use of JavaScript. Rather than
157 rehash these same arguments on the [forum][ffor], we distill the common
@@ -193,12 +214,12 @@
214 * ...[open source][flic] and [available][fsrc] to be inspected,
215 audited, and changed by its users.
216
217 * ...compiled directly into the `fossil` binary in a
218 non-obfuscated form during the build process, so there are no
219 third-party servers delivering mysterious, obfuscated JavaScript
220 code to the user.
221
222 C, Fossil's main implementation language, has been associated with
223 far more security problems than JavaScript, yet the apparent
224 alternative to reducing the amount of JavaScript in Fossil is to
225 increase the amount of C code. Does it not make sense to place as
@@ -284,11 +305,11 @@
305 command, by clicking around within the web UI, etc.
306
307 _Potential Workaround:_ The timeline could be enhanced with `<noscript>`
308 tags that replace the graph with a column of checkboxes that control
309 what a series of form submit buttons do when clicked, replicating the
310 current JavaScript-based features of the graph using client-server round-trips.
311 For example, you could click two of those checkboxes and then a button
312 labeled “Diff Selected” to replicate the current “click two nodes to
313 diff them” feature.
314
315 [wt]: https://fossil-scm.org/fossil/timeline
@@ -336,11 +357,11 @@
357
358 _Graceful Fallback:_ Unlike in the Fossil 2.11 and earlier days, there
359 is no longer a script-free wiki editor mode. This is not from lack of
360 desire, only because the person who wrote the new wiki editor didn’t
361 want to maintain three different editors. (New Ajaxy editor, old
362 script-free HTML form based editor, and old WYSIWYG JavaScript-based editor.) If
363 someone wants to implement a `<noscript>` alternative to the new wiki
364 editor, we will likely accept that [contribution][cg] as long as it
365 doensn’t interfere with the new editor. (The same goes for adding a
366 WYSIWYG mode to the new Ajaxy wiki editor.)
367
368

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button