For example, file www/caps/ref.html is rendered differently: compare fossil:/doc/trunk/www/caps/ref.html versus fossil:/file/www/caps/ref.html?ci=trunk.

In the later case the inline <style> is not applied to the document.
Why? Is that really desired?

It seems that /file page renderes *.html files via <iframe>. But for *.md (and perhaps *.wiki) files <iframe> is not used. Nevertheless inline <style> tags are intentionally broken, but only for the /file pages.
Why are <style> tags broken? Why inconsistently? Is it a feature or a bug?

In the later case the inline <style> is not applied to the document. Why? Is that really desired? ... Why inconsistently? Is it a feature or a bug?

The /file paths are (or were initially) intended for serving the raw content of files, not to be used as a replacement for /doc paths. They shouldn't (IMO) be able to affect the look and feel of the elements outside of that content. The /doc pages, on the other hand, are intended for serving arbitrary user-crafted docs and have more freedom in that regard.

Consider what would happen if a random file in the repo has a style tag block which sets the foreground and background colors to the same thing. If that style block was applied in the /file view, it would be impossible to view the file's contents via the /file page (and it could easily make the whole page invisible). Such a file would never be used as a /doc, so the project would never link to it as such. It's possible to browse through /file links to all files via the /dir page, but there are no automatic /doc links to files: those are created and published by the project's maintainers. Thus the rendering of /file needs to be somewhat conservative to keep pages from potentially breaking the site.

That said: i wasn't involved with the development of that feature, but that seems like a valid justification for intentionally reducing /file's functionality.

The /file paths are ... for serving the raw content

OK. That's fine, IMO.
Help about safe-html setting mentions STYLE tags; perhaps it should not?

Also it seems that *.md and *.wiki are handled differently.

Help about safe-html setting mentions STYLE tags; perhaps it should not?

That's a good question which i can't answer off the top of my head.

Also it seems that *.md and *.wiki are handled differently.

That's largely historical. STYLE blocks are not permitted in fossil-wiki docs unless (IIRC) the wiki-use-html^misref setting is enabled (and very few projects use that setting). In Markdown, on the other hand, STYLE blocks have always been permitted and were unproblematic until it was discovered that they can cause grief in the forum. Before the forum was added in 2018, style tags in markdown were never an issue and markdown had become the preferred format for new embedded docs by that point.

From the links you posted:

• Wiki-format file via /file
• Markdown-format file via /file

In the first one, it's doing what it has historically done: the style tag is not seen as a tag at all, and is thus rendered as plain text in the file view and in the doc view because the wiki-use-html setting is off.

Yes, there's an inconsistency, in that the markdown file renders the style tag in the /file view, but i think that's always been the case for markdown files. It could be fairly argued that style tags should not be rendered in /file but should in /doc, but so far the former has not been a problem for us. It would, however, be easy to construct a malicious style tag in such a doc which makes the whole site disappear when visiting that doc via a /file link: body{display:none}. Such an edit requires checkin access, though, and presumably people don't want to break their own repos, so that seems like a low-risk issue.

^misref = Achtung: the wiki-use-html setting can apparently only be toggled via the /setup_wiki page, does not show up in the settings help, and is not considered to be a setting by the set/unset commands. Not sure why.

---

1. ^{^ a b} Misreference

In the first one, it's doing what it has historically done: the style tag is not seen as a tag at all, and is thus rendered as plain text in the file view and in the doc view because the wiki-use-html setting is off.

That was worded somewhat ambiguously. My understanding is that if wiki-use-html is off (the default) then fossil-wiki docs never support STYLE tags in any view (/file or /doc). i just tested locally, and with wiki-use-html enabled, your demo page renders completely differently than intended because its content is interpreted as 100% HTML with no custom markup. Your STYLE tag remains intact but the PRE tags it is supposed to apply to are no longer in the HTML output because the <pre class='verbatim'> tags are (somewhat surprisingly) converted to <verbatim>. i'm not sure why that pre-to-verbatim conversion happens - it's a historical behaviour of the fossil wiki format.

i'm not sure why that pre-to-verbatim conversion happens - it's a historical behaviour of the fossil wiki format.

Correction: the fossil-wiki markup is a VERBATIM tag, which gets output as a pre.verbatim when it's rendered as fossil-format wiki. When toggling the wiki-use-html option, VERBATIM is no longer a known tag and is output as-is. Thus your demo STYLE tag, which is retained as a STYLE tag when wiki-use-html is enabled, doesn't apply to those tags.

The meaning of "unsafe" and "dangerous" in relation to 'safe-html' setting seems blurry. Besides the STYLE tags, FORM tags are also accepted (which contradicts the explanation on the /setup_wiki page).
I make use of FORM within a checked-in Markdown document in my repo (even though 'safe-html' is unset there).