On = (the hamburger menu), the underline is sticky when open.

i'm unable to reproduce that one.

I'd have expected underlines to only apply to the current tab in sticky fashion, for all tabs (except the last, which is special). As currently behaving, seems a little haphazard perhaps.

The underline on the Threads and Post menu entries is part of the CSS applied for the "active" class. That both Threads and Post have that CSS class at the same time looks like a site-specific skin-level bug to me (the main fossil forum site does not have that issue). Only one person here (drh) has admin-level access to the sqlite3 forum to tweak that, though.

Interestingly/strangely, Firefox doesn't underline those at all, despite having the CSS telling it to. It's clearly visible in the browser dev tools but FF seems to be ignoring that aspect of the style (a 2-pixel border along the bottom of those elements). That's just plain weird.

On About the underline goes away, it is not sticky.

That also seems like a skin-level bug: that link is not getting the "active" class assigned to it, so has no underlining. This might (not sure) be a side effect of /about being either a URL alias or intercepted by the front-end web server (it's not a path which comes preinstalled by fossil).

And of course, the SQLite tab completely moves away to a different website.

It is a different site. The forum and source repos are, like for the main fossil project, separate sites and the main sqlite site is not simply a fossil repo like the sqlite forum and fossil's main site are.

The underline on the Threads and Post menu entries is part of the CSS applied for the "active" class. That both Threads and Post have that CSS class at the same time looks like a site-specific skin-level bug to me

Cloning the sqlite forum reveals that it's caused by an overzealous wildcard check in the skin header:

if {[string match /$current_page* $url]}

Threads=>/forum

Post=>/forumnew

So when current_page is Threads, that also matches the Post link.

i'm attempting to patch this locally using th1's regex command instead of string match but have yet to find the magic pattern necessary for that case.

@drh this skin patch seems to fix the extra "active" flag on the sqlite forum Posts menu entry:

foreach {name url expr class} $mainmenu {
  if {![capexpr $expr]} continue
  if {[regexp "/($current_page|$current_page/.+)\$" "$url"]} {
      set class "active $class"
  }
  set url $home$url
  html "<a href='$url' class='$class'>$name</a>\n"
}

This works for me in a local clone, in any case.

Edit: fixed in fossil:769167578b47fcb2 for all skins which do 'active' marking.

On About the underline goes away, it is not sticky. On Threads, its sticky, but Post also gets a sticky underline. On Post, only itself gets the sticky underline (unlike above).

Those are all now resolved and online. Thank you for the report.

On = (the hamburger menu), the underline is sticky when open.

That one i still can't reproduce in FF or Chrome on a desktop, but can imagine that it maybe happens on mobile when tapping on the hamburger (where'd my tablet go?). Apropos: the missing active-menu-entry underlining on Firefox was also fixed.

Confirmed: The "active" class is sticky on the hamburger menu on mobile (FF on iPhone in my case) after opening and closing that menu. But if after the menu finishes its opening slide-in, you scroll the screen slightly, or make any other screen interaction, the highlight goes away. Investigating....

This is known as the "sticky hover problem". It seems to emerge because mobile browsers activate "hover" on a click but do not deactivate it after the click. There are work-arounds, but they are ugly. In as much as this is a really a bug in the mobile web browsers, we have decided to ignore the problem for now.

I wouldn't describe it as a bug but as a conceptual mismatch owing to fundamental differences in input device affordances. Capacitance touch screens don't have a way to reliably detect "hover," and even if they did, no one would want to leave their finger hovering over the screen in same the way that people leave their mouse cursor hovering over a UI element.

I reply not out of pedantry but to show that this problem is insoluble in principle short of delivering two different UIs depending on the target device, the mobile one not trying to do something with "hover" state at all.

Patches thoughtfully considered, y'all. :)

Might adding:

@media (hover: hover) {
  button:hover {
    border: 3px solid green; /* solves sticky problem */
  }
}

per https://css-tricks.com/solving-sticky-hover-states-with-media-hover-hover/ help?

Might adding: @media (hover: hover) ...

We actually tried that, but FF on Android apparently reports that it supports hover (or else it's refusing to reload the page and is stuck with a cached copy - it's seemingly impossible to tell which), so the hover stays stays active on tapping for that browser.

We decided (in /chat) to punt on the problem for the time being. As Warren says, though: patches...