This might be a good plan. But...

We are getting into a situation where there are many different ways to specify the skin, but we do not have a clear strategy for which take priority. We have:

1. The /skn_X/ skin specified by the URL
2. The skin specified by a cookie (proposed)
3. The skin specified by the --skin command-line option, or by the skin: parameter in the CGI script
4. The skin specified in the CONFIG table
5. The default skin (used if nothing else specified)

The fifth option (the default skin) is always overridden by the others, presumably. But among the other four, what is the precedence order? If all four are specified, which one should be used?

I propose that the order shown be used. The first skin specification in the list wins. Thus a /skn_X/ URL overrides the skin cookie, which overrides the --skin command-line option, which overrides the CONFIG table, which overrides the default. That is not the way it works now, I don't think. I belive the current code always gives priority to option (3), the --skin command-line option. But should it necessarily be so?

Perhaps the specific order is not as important as simply defining what the order is, so that we know when the behavior is correct.

If we can agree on a precedence order, I'll put in the code for a skin cookie.

I think you should swap 2 and 3, since -skin is an active choice on each call, whereas the cookie is active only on selection, after which it’s offered up passively by the browser.

That’s the guiding principle: most active to most passive.

but we do not have a clear strategy for which take priority

That was what stopped me when i sat down to write proof of concept code before posting.

I propose that the order shown be used. The first skin specification in the list wins.

i'm agreed on that except that i'm wondering if --skin and cookie should be swapped so that a site admin can force a single skin in the case others are not compatible with their site (due to heavy customization of their preferred skin). It would also simplify testing new skins with --skin, as there would be no chance of a cookie getting in the way.

I belive the current code always gives priority to option (3), the --skin command-line option. But should it necessarily be so?

For testing purposes it sure it convenient, but there's no reason (IMO) that /skn_X can't/shouldn't trump it. The whole reason for /skn is to explicitly select one, neither a cookie nor --skin should trump that.

If we can agree on a precedence order, I'll put in the code for a skin cookie.

My current preference would be to simply swap 2/3 your list, but that's primarily to simplify development of skins (which is solely what i use --skin for).

If there is a skin cookie, the /skn_X/ URL seems like it becomes superfluous. In its place, we have /skin/X/Y which sets the cookie and redirects to /Y.

The /skn_X/ URL hasn't been released yet, so I can safely remove it, right?

With that change, and with giving priority to --skin, the order becomes:

1. The --skin command-line option or the skin: parameter in the CGI script.
2. The "fossil-skin" cookie
3. The skin properties of the CONFIG table
4. The default skin.

Sounds sensible to me.

so I can safely remove it, right?

From a usability perspective i can imagine replacing the skin list on the /skins page with a drop-down or (even better) with links which lead back to that same page and set the display cookie.

One aspect of /skn_xxx which now suddenly bothers me is search bots: they can climb down the whole repo using distinct paths once per skin. As far as a bot is concerned, each one is a whole different section of the site.

Edit:

With that change, and with giving priority to --skin, the order becomes:

Agreed.

One aspect of /skn_xxx which now suddenly bothers me is search bots: they can climb down the whole repo using distinct paths once per skin.

That's exactly what I was thinking when I proposed doing away with /skn_X/. We still have /draftN/ though. Should we try to do that using a cookie as well?

We still have /draftN/ though. Should we try to do that using a cookie as well?

That's a good question. Those links aren't exposed anywhere but the skin config page, are they? Spiders tend to start at the top and follow links, so they presumably won't find any links to those unless they're stashed away in the wiki or embedded docs.

If we can agree on a precedence order,...

Alrighty then...

This still needs more testing but "works for me" so far:

https://fossil-scm.org/home/timeline?r=skin-preference-cookie

Notes:

• The priority order was slightly modified from what we discussed to take the /draft[1-9] pages into account: those trump all other settings, including --skin. Thus an admin who has set --skin for the site can still use /setup_skin to develop and test new skins. The draft paths are not exposed anywhere other than via the skin edit process.

• The full priority list can be found here.

• Passing skin=XYZ as a URL argument, regardless of the page, will select that skin (if possible, else it is silently ignored) and update the UDC to use that skin. The /skins page now uses that URL argument to select the skin because...

• /skn_XYZ/... paths are no longer recognized. We "could" redirect those to /...?skin=..., but that seems like overkill considering that we have never posted a released version which uses those paths. Better to let them die out, IMO, rather than allow them to become a maintenance burden.

• During the style end-of-page bits, the UDC is always rendered if it changed. The "udc" URL parameter is no longer honored by cookie_render(), and cookie_render() is now only called from the final style bits, rather than selectively on a per-page basis. Those which do not modify that cookie will not cause it to be emitted (unless the skin=XYZ URL argument causes it to get updated, but that happens during the CGI init phase).

Critiques and other feedback are welcomed. Testers are doubly welcomed (simplest is to visit the /skins page).

Edit 2 years later: as of src:/info/5feac634737660e0, the "udc" argument is once again required to update the cookie, but is implicit if ?skin=... is provided. See comments in that checkin for why.

Critiques and other feedback are welcomed. Testers are doubly welcomed (simplest is to visit the /skins page).

It seems that i've broken the ability to use a skin edited locally for that site. A fix is pending. (Edit: done.)

Is this going to become a standalone cookie (fossil-skin) or part of the session (fossil-7f123...)?
Because privacy-wise there's a world of difference between those. (Literal/human-readable cookies are less of a concern for GDPR/ePrivacy compliancy.)

I was thinking that the cookie would be named "fossil-skin" and the value would be the name of the desired skin. But I haven't tried to implement it yet, though, so I don't really know.

(Literal/human-readable cookies are less of a concern for GDPR/ePrivacy compliancy.)

Note that the hashed part of the name fossil-7f123... is an anti-hijacking measure, not a data obfuscation measure. It's essentially impossible for a malicious user to guess your login cookie's name. The value is itself a session ID, and those are conventionally almost always long hex (or similar) strings.