This is what I would call "an improvement opportunity", without being facetious. Not a real bug.

For several of the Fossil "stock" skins, including the default one, hyperlinks are rendered (after markdown processing, by all browsers I use) in a way that makes them difficult to distinguish from plain text without careful scrutiny. It takes more scrutiny than is consistent with reading at speeds common for those who read a lot. (This may be an eye color sensitivity or a monitor color calibration issue, but I have color vision in the normal range and have seen this on a number of monitors.)

This near-invisibility issue would be completely cured by following the usual and ubiquitous convention for hyperlinks, where they are colored differently and underlined.

It has slightly bugged me for quite awhile, (years), enough so that I often put <u> and </b> around hyperlinks that may not be obviously seen as links from context. I decided to mention it here after seeing somebody in the SQLite forum mention that they had simply overlooked a link.

If I was not such an HTML noob, I would go edit some .css or something, and put it on a branch for approval (or rejection or repair.)

If I was not such an HTML noob, I would go edit some .css or something, and put it on a branch for approval (or rejection or repair.)

FWIW, i agree and will make this change when i'm back on the computer¹ unless you beat me to it. The CSS style in question is:

https://developer.mozilla.org/en-US/docs/Web/CSS/text-decoration

And it simply needs to be applied (or changed) in src/default.css for the "a" selector, then it can be overridden per-skin if needed.

1. ^{^} in the morning unless this starts bugging me enough to keep me awake

With your assurance as to where, (not to mention that "simply"), I will do it on branch, soon, today. Being on a newish system here, I will need to get zlib and ssl setup to build and test, so it could be a few hours before I can think of merging to trunk.

With your assurance as to where, (not to mention that "simply"

It is quite possible that the skins all explicitly set this already, in which case they will override (cascade) the setting from default.css, but that's clumsy to confirm from this tablet. Their css is in skins/NAME/css.txt.

With some skins, hyperlinks are quite plainly distinguished. But it is always due to color alone. (I've often picked a stock skin just to make links visible, even when not a fan of the aesthetics.) So I think just adding an underline to the default, provided that is also the starting point for fancier skins, will be a good and unobjectionable solution.

That said, now would be a good time for contrary suggestions or objections.

(Added via edit:)

Now, after some study, I see that several skins have seen fit to doctor hyperlinks, but not line-styled generally -- just within some elements.

I also see that with this added to src/default.css: a { text-decoration-line: underline; text-decoration-style: solid; } , nothing like that appears in the forum post preview I can get from a local (just built) ./fossil server, nor in the style.css it names as its stylesheet. So I conclude my noobiness must be operative here, and I need to ferret out where the stylesheet actually comes from and from what it is built.

Mastering this may take more of this evening.

, nothing like that appears in the forum post preview I can get from a local (just built) ./fossil server, nor in the style.css it names as its stylesheet.

style.css is just an amalgamation of default.css followed by the skin's css (see src/style.c and search for "E: style.css"). A genuine issue when testing CSS changes is browser cache. Tips for testing testing changes to default.css or skins...

• Run fossil via CGI instead of "fossil server" so that you don't need to kill and restart the process on each test run.
• Keep the browser's dev tools open and, in the Network tab, make sure the "disable cache" toggle is set (it will be reverted as soon as the dev tools are closed).

i'm unable to sleep so will take a look at this now.

Now, after some study, I see that several skins have seen fit to doctor hyperlinks, but not line-styled generally -- just within some elements.

After having tried this locally, adding underlining everywhere indeed adds an unsightly amount of noise, most notably to the header part of each forum post.

How about we start with this minimal change, which just underlines links in forum post bodies:

Index: src/default.css
==================================================================
--- src/default.css
+++ src/default.css
@@ -930,6 +930,9 @@
 div.forumClosed > .forumPostBody {
   opacity: 0.7;
 }
+.forumPostBody a {
+  text-decoration: underline;
+}
 div.forumClosed > .forumPostHdr::before {
   content: "[CLOSED] ";
 }

:-?

I'll do that work, in part so you can sleep well. (It's past your bedtime, I imagine.)

Please restate or edit "crest right style".

Another potential solution is the use of the a::before pseudoelement to add a (small and tasteful, natch) icon to indicate a link 🔗 without crazy underlining everywhere.

This is always a situation where style choices will differ though, and clearly it is unwise to overload all of the functional user interface link elements (I realise this is not what is being discussed but needs explicitly rejecting).

As further evidence of personal taste I've never seen the (presumably US?) spelling of aesthetic before and it looks horrible 😆.

As further evidence of personal taste I've never seen the (presumably US?) spelling of aesthetic before and it looks horrible 😆.

This is natural language and we are all used to what we got used to :) Languages tend to get simplified (form follows function etc.) - even in those highly etymological (sigh) there are radical nations that e.g. change "aesthetic" to "esthetic", not to mention the heretics that changed it from "æsthetic" in the first place :)

Digression apart, I also do not remember seeing underlined hyperlinks lately - as in "this millenium". I vote therefore nay and am pretty sure there are better solutions lying around, some of which have been already mentioned.

I agree with all of this, and suspect you have deliberately repeated "esthetic" in order to trigger me again 😆

In support of this, I've stood up a mirror of this forum here with the Inskinerator Modern skin applied.

It's a read-only mirror, and it doesn't update automatically. The intent is that you log in as anonymous, but if for some reason you need a more full-featured user account, I've added jnd, a reference to Donald A. Norman's web site. If you can find the ISBN-10 of the latest edition of his most famous book, that's the password.

My prior post in this thread is mirrored here, for example. Note how the lighter highlight color, the larger default font, and the greater amount of whitespace solves the readability issue without adding ugly underscores everywhere.

I've also done this for the main Fossil-SCM source code repo, here. Note how the same set of base improvements in the skin improve the readability of the Git to Fossil Translation Guide.

I disagree with the solution. Underlines on hyperlinks are unsightly everywhere, which is why the default skin did away with them in the first place. This is one of those "accessibility über alles" solutions, the sort of things government legislatures pass without any consideration for esthetics.

I agree wholeheartedly with Warren and Daniel (and spindrift's aesthetic disgust and Daniel's digression into the aetiology of such bastardisation) and have to submit my vote for rejecting the underlined links.

Perhaps if it could be made opt-in for those who want it, but I'd have to object to making it on by default. I can't really add any more to the argument than Warren has already stated so well except to offer that I can't recall an instance of illegible hyperlinks being mentioned before this thread, and—subjectivity notwithstanding—in my N+1 experience, I find the links clearly visible on the few screens I view Fossil sites.

I suspect all this is a reaction to this post where I dropped a subtle hyperlink into a post that a later poster (#17) missed. With the blue highlight on, I can see how one might miss it, especially after it's been clicked and thus had its saturation reduced to be closer to the unstyled text color.

I therefore get the concern, but underscores everywhere creates a mess. Try cloning this forum and opening it under fossil ui with tip-of-trunk, where this esthetic (hah!) change has been merged to trunk without due discussion.

(Why do the UK people pronounce it ee-sthe-tic but then insist on starting the word with an "a", and then get mad when we drop the silent letter?)

wrt its noisy impact, I've already replied in /chat, but I wanted to say thanks for linking the thread because that's another interesting albeit entirely unrelated topic!

With the blue highlight on, I can see how one might miss it,
especially after it's been clicked and thus had its saturation
reduced to be closer to the unstyled text color

Unclicked, the pale blue text can be identified as a link.
But once clicked, I confirm it's barely distinguishable from regular text.

But let me add my vote to having links more visible, somehow.
Brighter blue? Underlined? Both? Subtle box around? with a small link logo?

At least with underlined, the clicked or unclicked states are equally visible, despite the color change!

And FWIW, I disagree that underlined links create a mess.

If it was a user option, I'd select to make-links-more-visible mode myself.
Lots of people are color blind, and underlined works better for them I guess too.

once clicked, I confirm it's barely distinguishable from regular text.

I've always interpreted that as a feature. From a visual display sense, this design choice says, "You've been here already; since you know what's on the other side of that link, chances are, you don't need to go there again." On the chance that this is wrong, you know it's there and are purposefully seeking it out; you won't overlook it in that context.

That said, it does look like I overrode this choice in Inskinerator Modern for some reason, despite the intent that it deviate from the Fossil Default colors as little as possible. Mainly the color differences are to collapse two very-close colors into a single definition in the interest of avoiding pointless divergences, not to make significant changes like this one.

Lots of people are color blind, and underlined works better for them I guess too.

Sure, but there are browser settings and extensions for cases where the user wants a local override.

But let me add my vote to having links more visible, somehow. Brighter blue? Underlined? Both? Subtle box around? with a small link logo?

Now that the underlined links are here, I have to say I don't hate it, but I agree with this.

What if the links were bold without underline? It's more obvious that way.

However, as is, I see people on the SQLite forum post a link without even making it a link, so there's that...

Why do the UK people pronounce it ee-sthe-tic but then insist on starting the word with an "a", and then get mad when we drop the silent letter?

We don't. It's closer to ass-thetic, but you really do get the subtle a-e vowel slur, which you may well not be able to discern if you aren't either a native (British) English speaker, or a European romance language speaker with similar vowel sounds.

Also bear in mind that regional accent variations in Britain will alter this production enormously.

However, I would never pronounce it "ee-sthe-tic”.

As a random off topic aside!

I've certainly heard it pronounced thus by <waves hand> Britishers, but I will concede it was possibly mispronounced on purpose to wind all us USians up for our collective decision to spell the word as we pronounce it, with a short "e" on the front.

In penance, I resolve to begin pronouncing "colour" with a "u" sound in the middle. "The clicked hyperlink has a bluish-gray colooor." 😛

As long as you don't call it blee and can still distinguish grene from blewe, I guess you're ok 😛.

Seriously, as a member of those "European (phonetical) romance language speaker" group (which, by the way, was taught BE in school - as in all Europe - and ditched it temporarily during the scientific research period to harmonise with the peer authors), I occasionally get the angst when I ponder that e.g. no O in "colo(u)r" gets pronounced as O 🙄. (Of course, I get an even bigger angst when I see phonetically written English text, because I am old enough to be conservative.)

Ah. You feer culur as much az aye feer esthetic then?

I promise I'm done with this tangent now!

Thanks Warren, all us Britishish folks have had a chat and we're grateful 👍

I suspect all this is a reaction to this post ...

Your suspicion is well founded as to a trigger. However, I have posted links in the SQLite forum many times, for years, with underlining for the benefit of likely recent forum participants who are likely to be using the default skin. I went to this trouble because I had seen people miss my links, and because (as I mentioned earlier), they can be difficult to see. So to say "all this is a reaction to this post" is a substantial overstatement.¹

I have been using a couple of monitors lately which have a newfangled feature where the plain white normally used for background becomes a little more or less bluish at certain times², and the more bluish background makes the hyperlinks even harder to see without close examination.

Lately, I have tried to use phrasing to provide a hint that a hyperlink is to be found. So that can be a partial mitigation. But it's a blunt tool.

Something to make hyperlinks more noticeable would be a real improvement. I am indifferent to what form that takes. They are rare enough in forum posts that the aesthetics matter very little, IMO. But I think form should not prevail over function for this.

1. ^{^} The phrase, "straw that broke the camel's back" comes to mind. More accurately, the one straw convinced me that it was not just a quirk of my own vision.
2. ^{^} This bluishness, or its absence, is alleged to interfere less with sleep rhythm or some such. Color me skeptical.

digression into the aetiology of such bastardisation

Um, you do mean etiology, right? :)

(Quiz: How many silent letters in thought are not dropped?)

Um, you do mean etiology

Mark is very clearly a gentleman of great culture, taste and education, and hopefully will ignore your impertinent attempt to colour the thread of discussion with such base assertions 😉

Perhaps if it [underlining] could be made opt-in for those who want it...

Sidebar: that did cross my mind but we don't currently have a way to dynamically expand text in the default CSS. We'd need to add th1 support to that file. That's fine in the skins, but the core CSS should be static, IMO, if only for the reason that making it configurable may inadvertently interfere with arbitrary skins when any given configurable part is swapped out.

In any case, The Underliners are in the clear minority, so let's roll back that change. We seem to be, by a very rough count, approximately evenly split on the fact that the legibility needs some improvement for link. Warren's Inskinerator example demonstrates that perhaps some slight spacing changes is all we really need.

Is there a single solution that works equally well for docs/wiki, the forum, and the timeline, or does each one have different pressures that informs the proper design choice?

My initial thought was that underlines should go everywhere, but after a couple minutes of looking at it locally it became clear that that was pretty horrid and opted for just the forum bodies. After having seen the traffic on the topic which came up during my sleep cycle...

I would rather we increase the contrast than add underlines.

i'm not at all averse to alternative solutions like contrast changes. Another alternative, if the objection is noise level, is simply to dull down the underline, making it dotted (effectively halving the surface area of the underline). i'm not strongly attached to any given solution, but do agree entirely with Larry that visibility of links in the forum is too low. It's never bothered me in the other pages and docs but often has in the forum.

Above all, let us not fall into the "developers doing design work" trap.

But it's worked so well for us so far! ;)

In support of this argument, I direct your attention to the docs for Inskinerator.

The legibility difference is indeed surprising. Please make it so :).

dull down the underline…dotted

Modern browsers let you affect the underline color separately.

Please make it so :).

To be clear, please confirm my understanding that you are not asking me to:

1. Merge Inskinerator into Fossil proper, thus putting a dependency on Perl and its CSS::Sass module, which understands only the now-deprecated second-of-three dialects of SCSS.¹ I would doubt you're asking me to do this even if it were all written in Tcl instead.

2. Replace the Default skin wholesale with the output of Inskinerator, which for practical implementation reasons makes no attempt to make the diffs as small as possible.

3. Produce a new Modern skin output by Inskinerator, based on Default but with minimal diffs.

To sum, what you are asking me to "make so" is the smallest possible diffs to Default that make it look like Inskinerator Modern, yes? It is with this understanding that I intend to proceed modifying Default toward Modern on a branch. I intend to proceed with an orderly series of commits that allow each element of the difference to be teased apart at need, even cherry-picked onto trunk if that's what the collective will demands.

1. ^{^} Yes, really. The original is now called Ruby Sass for clarity, then there's the C++ rewrite called libSass, which is what CSS::Sass compiles against, and then there's Dart Sass, the anointed replacement. (sigh)

Modern browsers let you affect the underline color separately.

That is nice :). i try to avoid colors in default.css (and app-level CSS like that for /*edit) simply because they're likely to conflict with at least one of the standard skins.

To sum, what you are asking me to "make so" is the smallest possible diffs to Default that make it look like Inskinerator Modern, yes?

Yes, noting that it's not really my decision to make! So long as Richard doesn't veto it, though, i get the impression that Inskinerator's approach is both solid and agreeable (or not disagreeable) to the majority.

Would it be an option to make Inskinerator Modern a new skin, so we can try it first and then decide whether or not to switch?

Also, I think the original problem of this post (reduced visibility of blue hyperlinks on blue background) can be solved without adapting the whole skin. I think the current default skin has been created earlier than the Forum feature (but I may be wrong), so the problem of blue-on-blue was introduced separately and should be solved separately?

try it first and then decide whether or not to switch?

Because the work is occurring on a branch, we already get that effect.

The only advantage of putting it into a different, named skin is if we decide not to merge it to trunk and then don't want to throw the work away.

The branch is approaching a testable state now, but if you wish to wait until it fully stabilizes, the mirrors linked above show the value of the changes. The work now is reverse-engineering all the changes in terms of Fossil's existing CSS. It's a fair bit of work, explaining the time lag between commits.

solved without adapting the whole skin

That's why I'm being careful to commit coherent pieces of Modern: so people can merge elements down to their trunk locally in a pick-and-choose manner.

Personally, I think it all hangs together quite well, but I'm not going to let this idea die or be put off for untold years more merely because one piece is deemed unacceptable. I've been trying to get traction on this since 2017. It's past time that some of this work, at least, gets merged into Fossil proper.

Because the work is occurring on a branch, we already get that effect.

Once merged to trunk, the original will be overwritten.

The original has served us well for many years, and our eyes, mouse movements and screen/window arrangements have become accustomed to it.

We have a lot of other skins we could throw away--in my opinion. But they are kept, likely because people are using them. Even more so I think it would be a pity to discard the original default.

I've been trying to get traction on this since 2017.

That happens, look at my open branches ;-) So it looks a bit like you're using the issue of poorly readable links as an opportunity to sell your feature--which is okay, but I'm just not happy with replacing the original.

it would be a pity to discard the original default.

The irony of that phrasing is that "original" is an entirely different skin, which was previously called "default," replaced in 2015.

In that spirit, I propose the current default be renamed to "Étienne", if only as a baseline for others to diff preexisting customized skins against, to ease migration.

I'm not going to do that on the branch under development, as it would produce a large diff merely to encode what amounts to a directory rename. That can wait until the last moment, either right before or right after the branch is merged.

you're using the issue of poorly readable links as an opportunity to sell your feature

While it is true that my skin changes go beyond fixing the single issue that started this thread, they are all in service of the broader goal: improve readability. Not just links, everything.

This is not a mere matter of taste. I have centuries of usability guidance on my side, going back to Gutenberg and beyond, and the reason for that is simple: human limitations have not noticeably changed since the days of the first printing presses.

1. Line length: This is extremely well-studied, to the point that it's as unassailable as anything gets in human factors. There's a good reason the only time you ever saw printed books with spreads 27 inches in diagonal was because they were picture books meant to "wow" you for a few minutes, only to be sat back down on the coffee table before arm-strain set in.

   When the ancient 80-column standard finally began to be displaced by large monitors, we added windowing and tiling systems to let us divide that up into areas with comfortable line lengths. I ran my Terminal windows at 80 columns wide (but full-height) for many years and only reluctantly increased that to 100 columns when I began using programming languages that encourage indenting things more than old ones did. Yet, do not take this as justification for 100+ column line lengths; the net effect is that most lines remain under 80 characters wide, once you discount the indent levels.

   While doing this work, I noticed that the <textarea> box in /forumedit pages is 80x25, and I chose not to change that for this very same reason.

2. Line spacing: The longer the lines, the more space between lines you need to get the eye to track reliably back from the end of one line to the start of the next. This, too, is proven to the point of unassailability. Since we can't reasonably make Fossil UI use 4-6 inch wide lines everywhere, we have to add some line spacing for proper readability.

   The dying newspaper industry can still teach us a few lessons about human factors before the last broadsheet printing press shuts down. For one, there's a good reason their bulk prose is laid out in narrow columns. When you're cramming the lines in as tight as you can, with zero leading and smallish fonts, you need column widths no greater than about 2 inches to allow rapid reading. That solution isn't available to us in Fossil UI. If we're going to assume window widths about equal to a piece of office paper, we need generous line spacing to compensate.

3. Hierarchy: The current Fossil default skin limits itself to header font sizes to indicate hierarchy. In short documents with only one or two levels of headers, this is fine, but there's a reason I pointed to a long document in my example above. Compare the Git to Fossil Translation Guide on my mirror with the one on trunk now. Which is more readable?

   Not only do my Modern improvements indent the headers and body text hierarchically — which also serves to reduce overlong line lengths — it increases the size of h1 so that you can have meaningful size differences down to h5. The current default skin stops at h3.

4. Font size: Browsers have settled on a "normal" font size for well-studied human-factors reasons, but Fossil's default skin runs everything at 80-90% of that size. My changes bring the baseline back up to 100%, where the bulk of those over a certain age need it to be.

   Me, I'll be 50 soon, and I've been wearing "Coke-bottle" glasses since I was 8. I haven't been able to run Fossil UI windows at 100% for years now.

   Those young and/or genetically lucky enough that 80-90% font sizes remain perfectly readable are free to invert my prior accommodation to these facts: hit Ctrl/Cmd-Minus in Fossil UI windows for sites running the Modern skin to bring the font sizes back down to where they were.

I see quite some "collecting" (grouping) of (homogenized) styles for unrelated features

I've done that only twice so far, and one of those was because I didn't plan out my sequence of changes as well as I should have, in retrospect. Since I do not believe you're attempting to advocate that I go and rebase history now to produce a cleaner set of diffs, I will point out that the current branch diff is rather clean regardless. The only large diff chunk is the pure addition made as part of the MD body text improvement commit, and that can't be diced up much finer than it already is without making the change pointlessly incoherent.

The other case was to collect monospace fonts together, and you can't seriously be arguing that I should repeat that long list of fonts in each of the five places it was previously used?

I think it should be a separate skin.

The purpose behind this thread and my work is to improve the default skin used on fossil-scm.org and sqlite.org. If this gets merged to trunk, it will be made to "default" for this reason. The only question is whether we shunt the current default off to another named skin around that time, which brings us right back to the top of this post.

Wishing to avoid turning this post into a Möbius strip, I choose to stop arguing here and get back to work.

I propose the current default be renamed to "Étienne", if only as a baseline for others to diff preexisting customized skins against, to ease migration.

EDIT: I've been given permission to merge my inskinerator-modern-backport branch to trunk, and I've rebuilt my containerized build of Fossil against this version, then deployed it to my web site. The mirrors will remain up, both in order to avoid breaking links in this thread and against further need, but don't expect the content to update regularly, if at all.

You can append "?skin=etienne" to the URLs on my mirrors to see the old skin applied to the new content. Once drh deploys trunk to his servers, you'll be able to do it here, too.

It's a toss-up whether you should roll back to the old docs when testing this fresh fork of the old default skin or not.

The "pro" side of that question is that Étienne continues to lack indenting on <pre> blocks and such. To get the full legacy experience, you'll need to roll back to the old manually-formatted versions of the docs by changing the traditional "/trunk/" part of the embedded doc URLs to "/5a09f499/", naming the last trunk commit before the new skin was merged. To the extent that my grep-fu allowed it, the manual indents have all been removed lest we end up with double-indenting under the new skin.

The "con" side is that the new Étienne skin isn't 100% identical to the prior trunk default skin. For one, it includes a monochrome variant of the table formatting from the new skin, without which the updated Fossil docs would render tables without any styling at all, not even cell borders. If you apply Étienne to the legacy version of the docs, you'll get double formatting on tables such as the ToC at the top of the Fossil v Git doc, which previously had local formatting.

This fork of the old default partially addresses the protest elsewhere in this thread about the blue tables. (And implicitly, the blue sidebars as well.) Here, for example, is the updated Fossil v Git doc with the table of contents in gray instead of blue. Personally, I think that's worse, but de gustibus non est disputandum, eh?

Étienne also inherits a monochrome variant of the sidebar styling from the core (src/default.css) skin. This is less important than the table styling, since unstyled sidebars merely end up inline. That isn't the worst thing, but I didn't see a good reason to strive for a strict historical match in this area.

Other than those details, Étienne is a straight copy of the trunk default skin, functionally speaking.

Another observation:

When reading the diffs available so far, I see quite some "collecting" (grouping) of (homogenized) styles for unrelated features and would like to point out that this makes editing (and merging) a skin by the user more complicated (anything outside src/default.css is intended to be adapted by users, in the end).

So this approach may break a lot of customizations, another reason why I think it should be a separate skin.

Edited to mention compatibility regarding custom skin merging/updating.

Please make it so :).

It is so. :)

I've manually overwritten my demo mirrors' skins, here:

• Fossil Source Repo
• Fossil Forum

I'm not aware of any cases where this isn't the same thing as rebuilding the Fossil binary and clearing the old skin config since the only purpose in that is to regenerate the CSS. There were no C-side changes needed to accomplish any of this.

Both repo mirrors were just pulled, but as before, I am not making any effort to keep them in lockstep. The purpose of these mirrors is to serve up familiar content examples, not to backstop the fossil-scm.org services.

I can be talked into reducing the header sizes somewhat. I'm find the use of "h1" for forum thread posts in particular a bit shouty. I could change forum.c to use h2 instead, but…

I've made a raft of improvements to all of this, so in case anyone's monitoring the progress and saw bugs they didn't report earlier, you might want to check again.

Please use these mirror URLs for testing instead of those in the prior post:

• Fossil Source Repo
• Fossil Forum

Links pursued from those bases will include the branch name in /doc URLs and such, which is necessary to see all the changes, especially in the case of embedded docs adjusted to work better with the skin changes.

One good example of this is the table at the top of the Fossil v Git doc. See here versus the current trunk version, here.

Please use these mirror URLs for testing instead of those in the prior post:

Additionally, https://fossil.wanderinghorse.net/r/ is running Warren's branch.

Things are settling into a stable state. The major changes since my last post to this thread are:

1. Mobile works better. Most testing before was on a desktop-class screen.
2. The new styles apply properly under the /fileedit and /wikiedit preview tabs.
3. While the skin was handling wiki-format embedded docs, it was ignoring old-style /wiki docs.
4. Added SO/GH/Reddit/Discord styling of inline code fragments. (Example) I can be talked out of this one, but if you hate it, you'd better be convincing. :)
5. EDIT: This thread's initial issue has been fixed two ways: fading the blue selected post color out to white, and use of a brighter, harder-to-miss blue for unvisited links.

Comments? Complaints? Requests?

Otherwise, I've only got one more experiment to try before I'm going to call this merge-able soon.

I like almost all of the changes, but I don't understand why the table in your example in point 2.0 is bluish? The main menu is grey, the inline code background is grey, but the table is blue. I don't quite like it... ;-)

Why is the cherry on the sundae red, not vanilla white or chocolate brown?

Accent.

:-) Why there must be a cherry? Ice cream itself is completely sufficient ;-)

Nice job, I like it.

I especially like point 4; we'll see if it sticks around.
Would that always require being enclosed in tt or will it work with the backticks?

You shouldn't use "<tt>" any more at all. That's a non-semantic tag specifying a particular type of formatting, so-called "typewriter text." The new skin does support it, but only for backwards compatibility.

HTML5 deprecated it in favor of code, var, samp, and kbd tags. Since Fossil's MD formatter can't know which one has the best semantic fit, it emits <code> for inline backticks. There are many places in the provided mirrors where you can see this in action and answer such questions on your own, but for your convenience, here is one where inline backticks are heavily used.

Your question inspired me to extend the current handling to var, samp, and kbd. This is now on the branch and deployed to the mirror server.

I remain uncertain whether to give <pre> the same treatment. Other MD formatters do, but we've got a big legacy, and I'm not sure it would work out well. The question remains open, but resolving this isn't a blocker.

EDIT: Redeployed the branch to the mirror server. Better example link.

You shouldn't use "" any more at all.

I asked about tt, because the fossil-v-git.wiki page is littered with them.

In your latter example (containers.md), I do see the backticks being used.

Thanks for your work on all of this!

the fossil-v-git.wiki page is littered with them

Yes, and one day I’ll get around to replacing them with semantic markup, but not today. Each one has to be done thoughtfully, selecting the one-in-four option that fits best. If it could be done by global search and replace, I would have done it long ago.