I was trying to add a feature to www/server.wiki that would take a table of OS/front-end values as in this proposal and generate the HTML and JavaScript event handlers needed to jump to one of the new www/server/$os/$frontend.md docs.

I failed early because the Fossil Wiki feature purposely disallows <script> tags. I can see how that rule makes sense on Wikipedia, and I can see that with some of the lower-privilege Fossil wiki capabilities like append only that you'd want the same restriction. However, I'm not really seeing why I should be restricted from adding such tags. I could just go stick the script into the skin, after all.

Even if I could get past that particular restriction, it wouldn't render due to the CSP nonce requirement, which then got me to thinking I'll need a way to call the Fossil TH1 nonce command.

And that in turn made me wonder if I could get everything I need with a new feature that would look something like this:

---

<th1>   <!--- interpreted much like <nowiki>, but run through TH1 -->
     puts "<script type='text/javascript' nonce='[nonce]'>"
</th1>
<nowiki>
    (function() {
        // <script> tag code goes here
    })();
</nowiki>
<th1>
     puts "</script>"
</th1>

---

That feature would have to be disallowed for users with append-only wiki capability, since that's often given to the anonymous or nobody group.

The writer of the text inside the <nowiki> boundary would have to be careful not to trigger any of the other automatic replacement logic in src/wiki.c, but I think you could write JS code fairly comfortably within the existing restrictions.

How about it? Can I have this feature, or am I just going to have to hand-write a bunch of links in www/server.wiki to www/server/os/frontend.md?

or am I just going to have to hand-write a bunch of links in www/server.wiki to www/server/os/frontend.md?

A possibly useful tip: when i have a long list of links or JSON data which i want to reconstruct into something else, but don't have an associated page to run the JS in, i'll often pack the data into a JS file, mutilate the data there, outputting its new form with console.debug(), paste that script into the browser's dev tools, and (finally) copy the output for use elsewhere. It's not pretty, but it works. (Yes, i'm aware that server-side JS is a thing nowadays, but i have personal hangups against using node.js and its brethren.)

I actually considered writing a Tcl script and tying it into the build system, much the same way as www/mkindex.tcl works, but then I saw that there's no "#include" feature in Fossil Wiki, either, so I'd have to generate the entire www/server.wiki page from it.

We're shaving yaks here....

My initial thought is that if you want to use JS, you need to go full-on HTML too. Instead of a markdown or wiki document, use the embedded-HTML style:

<div class='fossil-doc' data-title='TITLE'>
  ... document text here ...
</div>

I'm open to extending this mechanism with a new data-nonce=NAME parameter which causes Fossil to scan the content of the document and substitute all occurrences of the string "NAME" with the current nonce. For instance:

<div class='fossil-doc' data-title='TITLE' data-nonce='NONCEHERE'>
  blah blah blah
  <script nonce='NONCEHERE'>
    ...
  </script>
</div>

This would require changing the document suffix from ".wiki" or ".md" to ".html". But if we are talking about "server.wiki", I'm ok with that.

I didn't even know that was possible. Thanks.

But as for changing the name of the doc, isn't that one of the most linked-to pages on the site from outside?

Solution: set up a Fossil alias (Admin → URL Aliases) for it, pointing at the new doc location. Will that forward named anchor and ID references, though?

I've just discovered the index page support in /doc. How do you like www/server/index.html?

I won't make that change yet; I said I'll keep my hands off the tree for a while, and that I shall. Really. I'm just floating the trial balloon for now.

But as for changing the name of the doc, isn't that one of the most linked-to pages on the site from outside?

Hmm...

Ok, what if we enhance /doc so that for documents that consist of a exactly one line of text of the form

    redirect: RELATIVE-PATH

where RELATIVE-PATH is the relative pathname of a different embedded document on the same server, that it does a redirect? Or maybe instead of a redirect, it just loads the alternative document directly and doesn't even tell the client?

This behavior would apply to /doc only - not to /file or /artifact or /raw - and only if the /doc page omits the mimetype= query parameter.

I'm struggling to see the value. Fossil URL aliases sync, so we've already got the basic ability we need here.

Also, I've since verified that named anchor and ID references do work through Fossil aliases.

The only argument I can see in favor of your plan is that Fossil URL aliases don't participate in the check-in naming feature of /doc. That is, if you want /doc/trunk/foo.md and /doc/ckout/foo.md to point at the same /doc/*/foo/index.html file, with each pointing at the corresponding named version, Fossil URL aliases don't currently have the wildcard support needed to allow this.

So, if I can be greedy, what I'd like is regexes with group references support in URL aliases: /doc/(\w+)/foo.md → /doc/$1/foo/index.html.

That's PCRE syntax, which is something I'd also like, but if it has to be POSIX ERE, I can live with that. But please not BRE. :)

I've thought some more about this, and I think the current URL Aliases feature will suffice, since we can probably get by with only the /trunk alias. My argument above that server.wiki is widely linked-to only applies to the trunk version, so simple static aliases should suffice.

On the subject of query parameters, does Fossil understand any other query parameters when it is serving embedded docs, or is mimetype the only one?

It also accepts "name" as an alternative to the common method of naming /doc pages. These are equivalent:

    http://fossil-scm.org/fossil/doc?name=trunk/www/server.wiki
    http://fossil-scm.org/fossil/doc/trunk/www/server.wiki

There's also a "raw" parameter that Fossil only pays attention to in conjunction with the default-disabled TH1 docs feature.

I've just checked in a new feature on the server-docs branch to add support for nonce="$NONCE" substitution, working off the pattern of the pre-existing href="$ROOT" embedded documentation feature.

This new feature is on the branch because it's necessary for the new www/server/index.html file, which will shortly be getting a new <script> block, as previously discussed.

This check-in also documents $ROOT and TH1 docs for the first time, though the latter is really thin. We could use some examples. Surely someone is using TH1 docs under battle conditions?

(Apparently <script> isn't blocked the same way by our current CSP. Maybe it should be, now that we have a way around the problem that blocking it would create?)

The initial JS tutorial selector is working and checked in on the server-docs branch, but it doesn't work on fossil-scm.org yet because it requires this new nonce feature. I see several paths forward:

1. Temporarily disable the new JS code and remove the <noscript> wrapper around the old static <table> code, so people can at least play with the improved table.

2. Cherrypick my nonce feature into trunk and get it deployed onto fossil-scm.org.

3. Do all testing locally; if you want to see the new work, you need to be running the branch's version of Fossil locally.

Apparently <script> isn't blocked the same way by our current CSP.

Sorry, I meant <style>.

I went ahead and added a nonce attribute to the one in server/index.html, but I didn't look for uses of <style> elsewhere, so I don't know the impact of changing the CSP to disallow <style> without a nonce attribute.

I've just coincidentally stumbled across the ./configure --th1-docs feature, which appears to allow TH1 expressions inside curly braces within embedded docs.

It's default-disabled, though, and it looks like this plain-HTML option will suffice, so I don't think this feature request is going anywhere. I'm posting this in case someone else digs this thread up later and wants the option.