From 4f49b16079b27d7ce633619e4cddfdf2bffbc952 Mon Sep 17 00:00:00 2001
From: cashmere <cashmere@autistici.org>
Date: Fri, 4 Sep 2026 09:05:24 +0200
Subject: initial commit

---
 www/javascript.md | 642 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 642 insertions(+)
 create mode 100644 www/javascript.md

(limited to 'www/javascript.md')

diff --git a/www/javascript.md b/www/javascript.md
new file mode 100644
index 0000000..512837d
--- /dev/null
+++ b/www/javascript.md
@@ -0,0 +1,642 @@
+# Use of JavaScript in Fossil
+
+## Philosophy & Policy
+
+The Fossil development project’s policy is to use JavaScript where it
+helps make its web UI better, but to offer graceful fallbacks wherever
+practical. The intent is that the UI be usable with JavaScript
+entirely disabled. In almost all places where Fossil uses JavaScript,
+it is an enhancement to provided functionality, and there is always
+another way to accomplish a given end without using JavaScript.
+
+This is not to say that Fossil’s fall-backs for such cases are always as
+elegant and functional as a no-JS purist might wish. That is simply
+because [the vast majority of web users leave JavaScript unconditionally
+enabled](#stats), and of the small minority of those that do not, a
+large chunk use some kind of [conditional blocking](#block) instead,
+rather than disable JavaScript entirely.
+Fossil’s active developers do not deviate from that
+norm enough that we have many no-JS purists among us, so the no-JS case
+doesn’t get as much attention as some might want. We do [accept code
+contributions][cg], and we are philosophically in favor of graceful
+fall-backs, so you are welcome to appoint yourself the position of no-JS
+czar for the Fossil project!
+
+Evil is in actions, not in objects: we do not believe JavaScript *can*
+be evil. It is an active technology, but the actions that matter here
+are those of writing the code and checking it into the Fossil project
+repository. None of the JavaScript code in Fossil is evil, a fact we
+enforce by being careful about who we give check-in rights on the
+repository to and by policing what code does get contributed. The Fossil
+project does not accept non-trivial outside contributions.
+
+We think it’s better to ask not whether Fossil requires JavaScript but
+whether Fossil uses JavaScript *well*, so that [you can decide](#block)
+to block or allow Fossil’s use of JavaScript.
+
+The Fossil developers want to see the project thrive, and we achieve
+that best by making it usable and friendly to a wider audience than the
+minority of static web app purists.  Modern users generally expect a
+smoother experience than was available with 1990s style HTTP
+POST-and-response `<form>` based interaction. We also increase the set
+of potential Fossil developers if we do not restrict them to such
+antiquated methods.
+
+JavaScript is not perfect, but it's what we have, so we will use it
+where we find it advantageous.
+
+[cg]: ./contribute.wiki
+
+
+## <a id="debate"></a>Arguments Against JavaScript & Our Rebuttals
+
+There are many common arguments against the use of JavaScript. Rather than
+rehash these same arguments on the [forum][ffor], we distill the common
+ones we’ve heard before and give our stock answers to them here:
+
+1.  “**It increases the size of the page download.**”
+
+    The heaviest such pages served by Fossil only have about 15 kB of
+    compressed JavaScript. (You have to go out of your way to get Fossil
+    to serve uncompressed pages.) This is negligible, even over very
+    slow data connections. If you are still somehow on a 56 kbit/sec
+    analog telephone modem, this extra script code would download in
+    a few seconds.
+
+    Most JavaScript-based Fossil pages use less code than that.
+
+    Atop that, Fossil sends HTTP headers to the browser that allow it
+    to perform aggressive caching so that typical page loads will skip
+    re-loading this content on subsequent loads. These features are
+    currently optional: you must either set the
+    [`fossil server --jsmode bundle` option][fsrv] or the corresponding
+    `jsmode` control line
+    in your [`fossil cgi`][fcgi] script when setting up your
+    [Fossil server][fshome]. That done, Fossil’s JavaScript files will
+    load almost instantly from the browser’s cache after the initial
+    page load, rather than be re-transferred over the network.
+
+    Between the improved caching and the fact that it’s quicker to
+    transfer a partial Ajax page load than reload the entire page, the
+    aggregate cost of such pages is typically *lower* than the older
+    methods based on HTTP POST with a full server round-trip. You can
+    expect to recover the cost of the initial page load in 1-2
+    round-trips. If we were to double the amount of JavaScript code in
+    Fossil, the payoff time would increase to 2-4 round-trips.
+
+2.  “**JavaScript is slow.**”
+
+    It *was*, before September 2008. Google's introduction of [their V8
+    JavaScript engine][v8] taught the world that JavaScript need not be
+    slow. This competitive pressure caused the other common JavaScript
+    interpreters to either improve or be replaced by one of the engines
+    that did improve to approach V8’s speed.
+
+    Nowadays JavaScript is, as a rule, astoundingly fast. As the world
+    continues to move more and more to web-based applications and
+    services, JavaScript engine developers have ample motivation to keep
+    their engines fast and competitive.
+
+    Ajax partial page updates are faster than
+    the no-JS alternative, a full HTTP POST round-trip to submit new
+    data to the remote server, retrieve an entire new HTML document,
+    and re-render the whole thing client-side.
+
+3.  “<a id="3pjs"></a>**Third-party JavaScript cannot be trusted.**”
+
+    Fossil does not use any third-party JavaScript libraries, not even
+    very common ones like jQuery. Every bit of JavaScript served by the
+    stock version of Fossil was written specifically for the Fossil
+    project and is stored [in its code repository][fsrc].
+
+    Therefore, if you want to hack on the JavaScript code served by
+    Fossil and mechanisms like [skin editing][cskin] don’t suffice for your
+    purposes, you can hack on the JavaScript in your local instance
+    directly, just as you can hack on its C, SQL, and Tcl code. Fossil
+    is free and open source software, under [a single license][2cbsd].
+
+4.  “<a id="snoop"></a>**JavaScript and cookies are used to snoop on web users.**”
+
+    There is no tracking or other snooping technology in Fossil other than
+    that necessary for basic security, such as IP address logging on
+    check-ins. (This is in part why we have no [comprehensive user
+    statistics](#stats)!)
+
+    Fossil attempts to set two cookies on all web clients: a login session
+    cookie and a display preferences cookie. These cookies are restricted to
+    the Fossil instance, so even this limited data cannot leak between
+    Fossil instances or into other web sites.
+
+5.  “**JavaScript is fundamentally insecure.**”
+
+    JavaScript is certainly sometimes used for nefarious ends, but if we
+    wish to have more features in Fossil, the alternative is to add more
+    code to the Fossil binary, [most likely in C][fslpl], a language
+    implicated in [over 4× more security vulnerabilities][whmsl].
+
+    Therefore, does it not make sense to place approximately four times
+    as much trust in Fossil’s JavaScript code as in its C code?
+
+    The question is not whether JavaScript is itself evil, it is whether
+    its *authors* are evil. *Every byte* of JavaScript code used within
+    the Fossil UI is:
+
+    *   ...written by the Fossil developers, vetted by their peers.
+
+    *   ...[open source][flic] and [available][fsrc] to be inspected,
+        audited, and changed by its users.
+
+    *   ...compiled directly into the `fossil` binary in a
+        non-obfuscated form during the build process, so there are no
+        third-party servers delivering mysterious, obfuscated JavaScript
+        code blobs to the user.
+
+    Local administrators can [modify the repository’s skin][cskin] to
+    inject additional JavaScript code into pages served by their Fossil
+    server. A typical case is to add a syntax highlighter like
+    [Prism.js][pjs] or [highlightjs][hljs] to the local repository. At
+    that point, your trust concern is not with Fossil’s use of
+    JavaScript, but with your trust in that repository’s administrator.
+
+    Fossil's [default content security policy][dcsp] (CSP)
+    prohibits execution of JavaScript code which is delivered from
+    anywhere but the Fossil server which delivers the page. A local
+    administrator can change this CSP, but again this comes down to a
+    matter of trust with the administrator, not with Fossil itself.
+
+6.  “**Cross-browser compatibility is poor.**”
+
+    It most certainly was in the first decade or so of JavaScript’s
+    lifetime, resulting in the creation of powerful libraries like
+    jQuery to patch over the incompatibilities. Over time, the need for
+    such libraries has dropped as browser vendors have fixed the
+    incompatibilities.  Cross-browser JavaScript compatibility issues
+    which affect web developers are, by and large, a thing of the past.
+
+7.  “**Fossil UI works fine today without JavaScript. Why break it?**”
+
+    While this is true today, and we have no philosophical objection to
+    it remaining true, we do not intend to limit ourselves to only those
+    features that can be created without JavaScript. The mere
+    availability of alternatives is not a good justification for holding
+    back on notable improvements when they're within easy reach.
+
+    The no-JS case is a [minority position](#stats), so those that want
+    Fossil to have no-JS alternatives and graceful fallbacks will need
+    to get involved with the development if they want this state of
+    affairs to continue.
+
+8.  “<a id="stats"></a>**A large number of users run without JavaScript enabled.**”
+  
+    That’s not what web audience measurements say:
+
+    * [What percentage of browsers with javascript disabled?][s1]
+    * [How many people are missing out on JavaScript enhancement?][s2]
+    * [Just how many web users really disable cookies or JavaScript?][s3]
+
+    Our sense of this data is that only about 0.2% of web users had
+    JavaScript disabled while participating in these studies.
+
+    The Fossil user community is not typical of the wider web, but if we
+    were able to comprehensively survey our users, we’d expect to find
+    an interesting dichotomy. Because Fossil is targeted at software
+    developers, who in turn are more likely to be power-users, we’d
+    expect to find Fossil users to be more in favor of some amount of
+    JavaScript blocking than the average web user. Yet, we’d also expect
+    to find that our user base has a disproportionately high number who
+    run [powerful conditional blocking plugins](#block) in their
+    browsers, rather than block JavaScript entirely. We suspect that
+    between these two forces, the number of no-JS purists among Fossil’s
+    user base is still a tiny minority.
+
+9.  “<a id="block"></a>**I block JavaScript entirely in my browser. That breaks Fossil.**”
+
+    First, see our philosophy statements above. Briefly, we intend that
+    there always be some other way to get any given result without using
+    JavaScript, developer interest willing.
+
+    But second, it doesn’t have to be all-or-nothing. We recommend that
+    those interested in blocking problematic uses of JavaScript use
+    tools like [NoScript][ns] or [uBlock Origin][ubo] to *selectively*
+    block JavaScript so the rest of the web can use the technology
+    productively, as it was intended.
+
+    There are doubtless other useful tools of this sort. We recommend
+    these two only from our limited experience, not out of any wish to
+    exclude other tools.
+
+    The primary difference between these two for our purposes is that
+    NoScript lets you select scripts to run on a page on a case-by-case
+    basis, whereas uBlock Origin delegates those choices to a group of
+    motivated volunteers who maintain allow/block lists to control all
+    of this; you can then override UBO’s stock rules as needed.
+
+10. “**My browser doesn’t even *have* a JavaScript interpreter.**”
+
+    The Fossil open source project has no full-time developers, and only
+    a few of these part-timers are responsible for the bulk of the code
+    in Fossil. If you want Fossil to support such niche use cases, then
+    you will have to [get involved with its development][cg]: it’s
+    *your* uncommon itch.
+
+11. “<a id="compat"></a>**Fossil’s JavaScript code isn’t compatible with my browser.**”
+
+    The Fossil project’s developers aim to remain compatible with
+    the largest portions of the client-side browser base. We use only
+    standards-defined JavaScript features which are known to work in the
+    overwhelmingly vast majority of browsers going back approximately 5
+    years, at minimum, as documented by [Can I Use...?][ciu] We avoid use of
+    features added to the language more recently or those which are still in
+    flux in standards committees.
+
+    We set this threshold based on the amount of time it typically takes for
+    new standards to propagate through the installed base.
+
+    As of this writing, this means we are only using features defined in
+    [ECMAScript 2015][es2015], colloquially called “JavaScript 6.” That
+    is a sufficiently rich standard that it more than suffices for our
+    purposes, and it is [widely deployed][es6dep]. The biggest single
+    outlier remaining is MSIE 11, and [even Microsoft is moving their
+    own products off of it][ie11x].
+
+[2cbsd]:  https://fossil-scm.org/home/doc/trunk/COPYRIGHT-BSD2.txt
+[ciu]:    https://caniuse.com/
+[cskin]:  ./customskin.md
+[dcsp]:   ./defcsp.md
+[es2015]: https://ecma-international.org/ecma-262/6.0/
+[es6dep]: https://caniuse.com/#feat=es6
+[fcgi]:   /help/cgi
+[ffor]:   https://fossil-scm.org/forum/
+[flic]:   /doc/trunk/COPYRIGHT-BSD2.txt
+[fshome]: /doc/trunk/www/server/
+[fslpl]:  /doc/trunk/www/fossil-v-git.wiki#portable
+[fsrc]:   https://fossil-scm.org/home/file/src
+[fsrv]:   /help/server
+[hljs]:   https://fossil-scm.org/forum/forumpost/9150bc22ca
+[ie11x]:  https://techcommunity.microsoft.com/t5/microsoft-365-blog/microsoft-365-apps-say-farewell-to-internet-explorer-11-and/ba-p/1591666
+[ns]:     https://noscript.net/
+[pjs]:    https://fossil-scm.org/forum/forumpost/1198651c6d
+[s1]:     https://blockmetry.com/blog/javascript-disabled
+[s2]:     https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/
+[s3]:     https://w3techs.com/technologies/overview/client_side_language/all
+[ubo]:    https://github.com/gorhill/uBlock/
+[v8]:     https://en.wikipedia.org/wiki/V8_(JavaScript_engine)
+[whmsl]:  https://www.whitesourcesoftware.com/most-secure-programming-languages/
+
+
+----
+
+## <a id="uses"></a>Places Where Fossil’s Web UI Uses JavaScript
+
+This section documents the areas where Fossil currently uses JavaScript
+and what it does when these uses are blocked. It also gives common
+workarounds where necessary.
+
+
+### <a id="timeline"></a>Timeline Graph
+
+Fossil’s [web timeline][wt] uses JavaScript to render the graph
+connecting the visible check-ins to each other, so you can visualize
+parent/child relationships, merge actions, etc. We’re not sure it’s even
+possible to render this in static HTML, even with the aid of SVG, due to
+the vagaries of web layout among browser engines, screen sizes, etc.
+
+Fossil also uses JavaScript to handle clicks on the graph nodes to allow
+diffs between versions, to display tooltips showing local context, etc.
+
+_Graceful Fallback:_ When JavaScript is disabled, this column of the
+timeline simply collapses to zero width. All of the information you can
+get from the timeline can be retrieved from Fossil in other ways not
+using JavaScript: the “`fossil timeline`” command, the “`fossil info`”
+command, by clicking around within the web UI, etc.
+
+_Potential Workaround:_ The timeline could be enhanced with `<noscript>`
+tags that replace the graph with a column of checkboxes that control
+what a series of form submit buttons do when clicked, replicating the
+current JavaScript-based features of the graph using client-server round-trips.
+For example, you could click two of those checkboxes and then a button
+labeled “Diff Selected” to replicate the current “click two nodes to
+diff them” feature.
+
+[wt]: https://fossil-scm.org/home/timeline
+
+
+### <a id="wedit"></a>The New Wiki Editor
+
+The [new wiki editor][fwt] has many new features, a
+few of which are impossible to get without use of JavaScript.
+
+First, it allows in-browser previews without losing client-side editor
+state, such as where your cursor is. With the old editor, you had to
+re-locate the place you were last editing on each preview, which would
+reduce the incentive to use the preview function. In the new wiki
+editor, you just click the Preview tab to see how Fossil interprets your
+markup, then click back to the Editor tab to resume work with the prior
+context undisturbed.
+
+Second, it continually saves your document state in client-side storage
+in the background while you’re editing it so that if the browser closes
+without saving the changes back to the Fossil repository, you can resume
+editing from the stored copy without losing work. This feature is not so
+much about saving you from crashes of various sorts, since computers are
+so much more reliable these days. It is far more likely to save you from
+the features of mobile OSes like Android and iOS which aggressively shut
+down and restart apps to save on RAM. That OS design philosophy assumes
+that there is a way for the app to restore its prior state from
+persistent media when it’s restarted, giving the illusion that it was
+never shut down in the first place. This feature of Fossil’s new wiki
+editor provides that.
+
+With this change, we lost the old WYSIWYG wiki editor, available since
+Fossil version 1.24. It hadn’t been maintained for years, it was
+disabled by default, and no one stepped up to defend its existence when
+this new editor was created, replacing it. If someone rescues that
+feature, merging it in with the new editor, it will doubtless require
+JavaScript in order to react to editor button clicks like the “**B**”
+button, meaning “make \[selected\] text boldface.” There is no standard
+WYSIWYG editor component in browsers, doubtless because it’s relatively
+straightforward to create one using JavaScript.
+
+_Graceful Fallback:_ Fossil’s lack of
+a script-free wiki editor mode is not from lack of
+desire, but because the person who wrote the new wiki editor didn’t
+want to maintain three different editors. (New Ajaxy editor, old
+script-free HTML form based editor, and the old WYSIWYG JavaScript-based
+editor.) If someone wants to implement a `<noscript>` alternative to the
+new wiki editor, we will likely accept that [contribution][cg] as long
+as it doesn’t interfere with the new editor. (The same goes for adding
+a WYSIWYG mode to the new Ajaxy wiki editor.)
+
+_Workaround:_ You don’t have to use the browser-based wiki editor to
+maintain your repository’s wiki at all. Fossil’s [`wiki` command][fwc]
+lets you manipulate wiki documents from the command line. For example,
+consider this Vi based workflow:
+
+```shell
+$ vi 'My Article.wiki'                   # begin work on new article
+  ...write, write, write...
+:w                                       # save changes to disk copy
+:!fossil wiki create 'My Article' '%'    # current file (%) to new article
+  ...write, write, write some more...
+:w                                       # save again
+:!fossil wiki commit 'My Article' '%'    # update article from disk
+:q                                       # done writing for today
+
+  ....days later...
+$ vi                                     # work sans named file today
+:r !fossil wiki export 'My Article' -    # pull article text into vi buffer
+  ...write, write, write yet more...
+:w !fossil wiki commit -                 # vi buffer updates article
+```
+
+Extending this concept to other text editors is an exercise left to the
+reader.
+
+[fwc]: /help/wiki
+[fwt]: ./wikitheory.wiki
+
+
+### <a id="fedit"></a>The File Editor
+
+Fossil’s [optional file editor feature][fedit] works
+much like [the new wiki editor](#wedit), only on files committed to the
+repository.
+
+The original designed purpose for this feature is to allow [embedded
+documentation][edoc] to be interactively edited in the same way that
+wiki articles can be. (Indeed, the associated `fileedit-glob` feature
+allows you to restrict the editor to working *only* on files that can be
+treated as embedded documentation.) This feature operates in much the
+same way as the new wiki editor, so most of what we said above applies.
+
+_Workaround:_ This feature is an alternative to Fossil’s traditional
+mode of file management: clone the repository, open it somewhere, edit a
+file locally, and commit the changes.
+
+_Graceful Fallback:_ There is no technical reason why someone could not
+write a `<noscript>` wrapped alternative to the current JavaScript based
+`/fileedit` implementation. It would have all of the same downsides as
+the old wiki editor: the users would lose their place on each save, they
+would have no local backup if something crashes, etc. Still, we are
+likely to accept such a [contribution][cg] as long as it doesn’t
+interfere with the new editor.
+
+[edoc]:  /doc/trunk/www/embeddeddoc.wiki
+[fedit]: /doc/trunk/www/fileedit-page.md
+
+
+### <a id="ln"></a>Line Numbering
+
+When viewing source files, Fossil offers to show line numbers in some
+cases. ([Example][mainc].) Toggling them on and off is currently handled
+in JavaScript, rather than forcing a page-reload via a button click.
+
+_Workaround:_ Manually edit the URL to give the “`ln`” query parameter
+per [the `/file` docs](/help/www/file).
+
+_Potential Better Workaround:_ Someone sufficiently interested could
+[provide a patch][cg] to add a `<noscript>` wrapped HTML button that
+would reload the page with this parameter included/excluded to implement
+the toggle via a server round-trip.
+
+A related feature is Fossil’s JavaScript-based interactive method
+for selecting a range of lines by clicking the line numbers when they’re
+visible. JavaScript lets us copy the resulting URL to the clipboard
+to share your selection with others.
+
+_Workaround:_ These interactive features would be difficult and
+expensive (in terms of network I/O) to implement without JavaScript.  A
+far simpler alternative is to manually edit the URL, per above.
+
+[mainc]: https://fossil-scm.org/home/artifact?ln&name=87d67e745
+
+
+### <a id="sxsdiff"></a>Side-by-Side Diff Mode
+
+The default “diff” view is a side-by-side mode. If either of the boxes
+of output — the “from” and “to” versions of the repo contents for that
+check-in — requires a horizontal scroll bar given the box content, font
+size, browser window width, etc., both boxes will usually end up needing
+to scroll since they should contain roughly similar content. Fossil
+therefore scrolls both boxes when you drag the scroll bar on one because
+if you want to examine part of a line scrolled out of the HTML element
+in one box, you probably want to examine the same point on that line in
+the other box.
+
+_Graceful Fallback:_ Manually scroll both boxes to sync their views.
+
+### <a id="diffcontext"></a>Diff Context Loading
+
+Fossil’s diff views can
+dynamically load more lines of context around changed blocks. The UI
+controls for this feature are injected using JavaScript when the page
+initializes and make use of XHR requests to fetch data from the
+fossil instance.
+
+_Graceful Fallback:_ The UI controls for this feature do not appear
+when JS is unavailable, leaving the user with the "legacy" static diff
+view.
+
+
+### <a id="sort"></a>Table Sorting
+
+On pages showing a data table, the column headers may be clickable to do
+a client-side sort of the data on that column.
+
+_Potential Workaround:_ This feature could be enhanced to do the sort on
+the server side using a page re-load.
+
+
+### <a id="tree"></a>File Browser Tree View
+
+The [file browser’s tree view mode][tv] uses JavaScript to handle clicks
+on folders so they fold and unfold without needing to reload the entire
+page.
+
+_Graceful Fallback:_ When JavaScript is disabled, clicks on folders
+reload the page showing the folder contents instead. You then have to
+use the browser’s Back button to return to the higher folder level.
+
+[tv]: https://fossil-scm.org/home/dir?type=tree
+
+
+### <a id="hash"></a>Version Hashes
+
+In several places where the Fossil web UI shows a check-in hash or
+similar, hovering over that check-in shows a tooltip with details about
+the type of artifact the hash refers to and allows you to click to copy
+the hash to the clipboard.
+
+_Graceful Fallback:_ When JavaScript is disabled, these tooltips simply
+don’t appear, but you can still select and copy the hash using your
+platform’s “copy selected text” feature.
+
+
+### <a id="bots"></a>Anti-Bot Defenses
+
+Fossil has [anti-bot defenses][abd], and it has some JavaScript code
+that, if run, can drop some of these defenses if it decides a given page
+was loaded on behalf of a human, rather than a bot.
+
+_Graceful Fallback:_ You can use Fossil’s anonymous login feature to
+convince the remote Fossil instance that you are not a bot. Coupled with
+[the Fossil user capability system][caps], you can restore all
+functionality that Fossil’s anti-bot defenses deny to random web clients
+by default.
+
+[abd]:  ./antibot.wiki
+[caps]: ./caps/
+
+
+### <a id="hbm"></a>Hamburger Menu
+
+Several of the stock skins (including the default) include a “hamburger menu” (&#9776;) which uses
+JavaScript to show a simplified version of the Fossil UI site map using
+an animated-in dropdown.
+
+_Graceful Fallback:_ Clicking the hamburger menu button with JavaScript
+disabled will take you to the `/sitemap` page instead of showing a
+simplified version of that page’s content in a drop-down.
+
+_Workaround:_ You can remove this button by [editing the skin][cskin]
+header.
+
+
+### <a id="clock"></a>Clock
+
+Some stock Fossil skins include JavaScript-based features such as the
+current time of day. The Xekri skin includes this in its header, for
+example. A clock feature requires JavaScript to get the time on initial
+page load and then to update it once a minute.
+
+You may observe that the server could provide the current time when
+generating the page, but the client and server may not be in the same
+time zone, and there is no reliably-provided information from the client
+that would let the server give the page load time in the client’s local
+time zone. The server could only tell you *its* local time at page
+request time, not the client’s time. That still wouldn’t be a “clock,”
+since without client-side JavaScript code running, that part of the page
+couldn’t update once a second.
+
+_Potential Graceful Fallback:_ You may consider showing the server’s
+page generation time rather than the client’s wall clock time in the
+local time zone to be a useful fallback for the current feature, so [a
+patch to do this][cg] may well be accepted. Since this is not a
+*necessary* Fossil feature, an interested user is unlikely to get the
+core developers to do this work for them.
+
+
+### <a id="chat"></a>Chat
+
+The [chat feature](./chat.md) is deeply dependent
+on JavaScript. There is no obvious way to do this sort of thing without
+active client-side code of some sort.
+
+_Potential Workaround:_ It would not be especially difficult for someone
+sufficiently motivated to build a Fossil chat gateway, connecting to
+IRC, Jabber, etc. The messages are stored in the repository’s `chat`
+table with monotonically increasing IDs, so a poller that did something
+like
+
+    SELECT xfrom, xmsg FROM chat WHERE msgid > 1234;
+
+…would pull the messages submitted since the last poll. Making the
+gateway bidirectional should be possible as well, as long as it properly
+uses SQLite transactions.
+
+### <a id="brlist"></a>List of branches
+
+The [`/brlist`](/brlist) page uses JavaScript to enable
+selection of several branches for further study via `/timeline`.
+Client-side script interactively responds to checkboxes' events
+and constructs a special hyperlink in the submenu.
+Clicking this hyperlink loads a `/timeline` page that shows
+only these selected branches (and the related check-ins).
+
+_Potential Workaround:_ A user can manually construct an appropriate
+regular expession and put it into the "Tag Filter" entry of the
+`/timeline` page (in its advanced mode).
+
+----
+
+## <a id="future"></a>Future Plans for JavaScript in Fossil
+
+As of mid-2020, the informal provisional plan is to increase Fossil
+UI's use of JavaScript considerably compared to its historically minimal
+uses. To that end, a framework of Fossil-centric APIs is being developed
+in conjunction with new features to consolidate Fossil's historical
+hodgepodge of JavaScript snippets into a coherent code base.
+
+When deciding which features to port to JavaScript, the rules of thumb
+for this ongoing effort are:
+
+-  Pages which primarily display data (e.g. the timeline) will remain
+   largely static HTML with graceful fallbacks for all places they do
+   use JavaScript. Though JavaScript can be used effectively to power
+   all sorts of wonderful data presentation, Fossil currently doesn't
+   benefit greatly from doing so. We use JavaScript on these pages only
+   to improve their usability, not to define their primary operations.
+
+-  Pages which act as editors of some sort (e.g. the `/info` page) are
+   prime candidates for getting the same treatment as the old wiki
+   editor: reimplemented from the ground up in JavaScript using Ajax
+   type techniques. Similarly, a JS-driven overhaul is planned for the
+   forum’s post editor.
+
+These are guidelines, not immutable requirements. Our development
+direction is guided by our priorities:
+
+1) Features the developers themselves want to have and/or work on.
+
+2) Features end users request which catch the interest of one or more
+developers, provided the developer(s) in question are in a position to
+expend the effort.
+
+3) Features end users and co-contributors can convince a developer into
+coding even when they really don't want to.
+
+In all of this, Fossil's project lead understandably has the final
+say-so in whether any given feature indeed gets merged into the mainline
+trunk. Development of any given feature, no matter how much effort was
+involved, does not guarantee its eventual inclusion into the public
+releases.
-- 
cgit v1.3.1