The css and js files are displayed as plain text in the desired manner.

There is not currently a configuration option for that, but...

IMO we should be displaying plain text, rather than rendered HTML, in that case, but that's a change we will need to get approval from Richard for. It seems unlikely that there are many cases - essentially only HTML-format wiki pages - in which rendering full HTML there will render the content properly/as desired.

I am prepared to recompile fossil if that is required.

As a quick-hack, until we can discuss this with Richard, i'll suggest an ugly workaround...

The decision to render that as HTML appears (untested) to happen here:

https://fossil-scm.org/fossil/file?udc=1&ln=2340-2344&ci=70bf9a6bf7588051&name=src%2Finfo.c

Hypothetically, removing that last highlighted line, or changing its value to 0, should do the trick for you for the time being.

Thank you Stephan for your very prompt and precise reply. I had spent more than an hour scanning the source files but did not look in info.c and would not have found the area of interest if I had.

Using the fossil-2.12-preview-20200801 source tarball, I changed the value to renderAsHtml = 0 and recompiled. The display for .html files is now as desired.

One further change is to remove the next line:

style_submenu_element("Text", "%s", url_render(&url, "txt", "1", 0, 0));

which removes the Text item from the sub-menu. This makes sense when the display is already in text mode.

Yet another change, which I did not apply, is to alter that style_submenu_element call to display the "Html" item. This would have the effect of allowing the display to show html after a user click, reversing the version 2.11 activity. Since the css and js displays have no equivalent alternative display, it is not of interest to me.

I had spent more than an hour scanning the source files but did not look in info.c and would not have found the area of interest if I had.

There's a simple trick to it: when searching for the source code for a given page, grep the C files for "E: pagename". That will find the "WEBPAGE: pagename" marker in the comments, and that marker is used by a code generator to map that function to the web page and generate the help text. From there it's a matter of following the code to find the piece you're looking for (in this case i tracked it down the txt URL parameter).

For CLI commands the equivalent search is "D: commandname".

essentially only HTML-format wiki pages

No: there's also HTML-formatted embedded docs.

The current behavior is therefore documented, thus not likely to change short of having a new default-disabled setting to control it.

Examples of pages in the Fossil repo using both behaviors:

• skin-wrapped: https://fossil-scm.org/home/doc/trunk/www/permutedindex.html
• straight-to-browser: https://fossil-scm.org/fossil/doc/trunk/www/uitest.html

If your HTML files reference CSS and JS via relative paths, and if you arrange your files in the repo in the same hierarchy as they appear when installed on the server, then viewing HTML source files as HTML should work normally. The proper CSS and JS should be fetched, and everything should just work. Are you finding that is not the case? Can you provide a concrete example to demonstrate the problem?

I kind of like that HTML files are displayed as HTML when you click on them.

Nevertheless, if there is a huge outcry for yet another configuration option that causes file content to always be delivered as text/plain, then I won't veto the change.

As stated in my original post which posed the problem, there are actually up to 4 components to each finished html file: optional custom css, optional custom js, required unique html content fragment, and a required template html file that contains the usual DOCTYPE, head, and body segments.

The finished html file is not part of the repository.

The unique html content fragment is not a complete web page and does not contain the references to the css and js files, so attempts to display it as html are highly likely to misrepresent its content. Sometimes the result is downright ugly. :-)

I suppose the fragment files could have another file extension thus avoiding fossil's default action, but it suits the rest of the development environment to label them as .html.

I have temporarily made nobody able to view the repository contents at:

https://doc.kixkolearning.com/library.cgi/lms-v3-es

Browsing down "Files/gotpl/public/content" will show the non-template files that are used in assembling a web page. The .html files are fragments.

The template file is stored in "Files/gotpl/public/templates".

A bundler program written in Go, using the Go template library, is driven by make and references the {? ... ?} tags in the required template file.

The required template file contents are common across many web pages so repetitive typing is avoided.

Merging the custom css and custom js into the finished file makes development so much easier since the browser and supply chain are not tempted to cache these components. I've been confused many times by that issue. And the resulting single file avoids up to 2 more calls to the server for what are usually small files.

There has been no activity in the offered repository so the access via nobody has been disabled.

If anyone wants to have another look then please reply to this note.

Thanks,

Chris

If your HTML files reference CSS and JS via relative paths, and if you arrange your files in the repo in the same hierarchy as they appear when installed on the server, then viewing HTML source files as HTML should work normally. The proper CSS and JS should be fetched, and everything should just work.

Feel free to correct me if I'm misunderstanding you, but here are my observations. I have a repo containing an HTML file with <link rel="stylesheet" href="file.css">, <script src="file.js"></script>, <img src="file.svg">, all referring to files in the same directory. When following a link from the directory view to the artifact view (/artifact/artifact-id) of the HTML file, I get presented with an HTML page loading an iframe from /raw/file-path?name=artifact-id.

When the iframe tries to load its dependencies from the same directory (from /raw/file-path without ?name=artifact-id), the result is a 302 redirect to /timeline. I don't consider it to be a problem, especially since /doc/branch/file-path works as expected.

The behaviour is the same on Fossil 2.8 from Debian backports and 2.12 [d0749d7886] from 2020-07-24 I built myself to keep track of new features.