Philosophy & Policy
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
<form> based interaction. We also increase the set
of potential Fossil developers if we do not restrict them to such
“It increases the size of the page download.”
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 new
fossil server --jsmode bundleoption or the corresponding
jsmodecontrol line in your
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.
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!)
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.
- ...written by the Fossil developers, vetted by their peers.
- ...open source and available to be inspected, audited, and changed by its users.
- ...compiled directly into the
“Cross-browser compatibility is poor.”
The no-JS case is a minority position, 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.
That’s not what web audience measurements say:
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.
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: it’s your uncommon itch.
We set this threshold based on the amount of time it typically takes for new standards to propagate through the installed base.
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
fossil timeline” command, the “
command, by clicking around within the web UI, etc.
Potential Workaround: The timeline could be enhanced with
tags that replace the graph with a column of checkboxes that control
what a series of form submit buttons do when clicked, replicating the
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.
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.
Graceful Fallback: Unlike in the Fossil 2.11 and earlier days, there
is no longer a script-free wiki editor mode. This is not from lack of
desire, only because the person who wrote the new wiki editor didn’t
want to maintain three different editors. (New Ajaxy editor, old
editor.) If someone wants to implement a
<noscript> alternative to the
new wiki editor, we will likely accept that contribution 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
lets you manipulate wiki documents from the command line. For example,
consider this Vi based workflow:
$ 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.
The original designed purpose for this feature is to allow embedded
documentation to be interactively edited in the same way that
wiki articles can be. (Indeed, the associated
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
/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 as long as it doesn’t
interfere with the new editor.
Workaround: Manually edit the URL to give the “
ln” query parameter
Potential Better Workaround: Someone sufficiently interested could
provide a patch 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.
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.
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.
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: 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, you can restore all functionality that Fossil’s anti-bot defenses deny to random web clients by default.
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 header.
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 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.
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
table with monotonically increasing IDs, so a poller that did something
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.
Since Fossil 2.16 the
selection of several branches for further study via
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).
Pages which act as editors of some sort (e.g. the
These are guidelines, not immutable requirements. Our development direction is guided by our priorities:
Features the developers themselves want to have and/or work on.
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.
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.