38 ms·

For language, use the Accept-Language header. For login, use basic/digest auth, or SASL (although, as far as I know, HTTP(S) doesn't have SASL, unfortunately).

For language, use the Accept-Language header. For login, use basic/digest auth, or SASL (although, as far as I know, HTTP(S) doesn't have SASL, unfortunately). For dark mode, printing, mono/colours, use CSS media queries. For table of contents, ensure the <H1>, <H2>, etc is valid. For timezones and time formats, use the <TIME> command. For data tables, use the <TABLE> command; you can also include links to data in CSV, JSON, etc. For footnotes, use the <FN> command. For some things, you can use CSS classes which are not necessarily referred to in the CSS code that you have; the user can apply their own if they want special styles for some things that you don't have styles for. In other words, many things will not need cookies/scripts. If you do use the, ensure that they are fully documented, and that the documentation can be viewed without cookies/scripts/CSS enabled. This allows the user to know exactly what is being done, as well as the possibility to enable only the cookies they want, or to manually configure read-only cookies for preferences.

mattmanser 6y ago
It was a while ago now but I'm pretty certain that I read some comments here saying using Accept-Language is often a bad idea. From what I remember, your IT department may muck it up, or you're using a shared computer at say a hostel and someone's set it and you don't know how to change it, etc. Aside from that, most of your examples need a lot of foresight, work and knowledge to actually pull off.
- zzo38computer 6y ago
  That is a valid consideration; it can use the URL to override the Accept-Language header (and the document can also include links for other languages, if appropriate). Likewise, the URL can also be used to override the Accept header.
toast0 6y ago
Accept-language is an okish default, but web pages end up needing to provide overrides because users are not always in control of those values, or the user may have preferences that don't fit the scheme. A cookie is a reasonable place to store the override. Http login is really hard to make user friendly, and has no way to logout in a user friendly way; the user needs to be prompted for a password again and not enter it. An HTML form and cookies just works better.
- zzo38computer 6y ago
  For languages, yes, overrides could be stored in a cookie, although they could also be stored in the URL (especially for documents intended to be downloaded). It could also support both. The reasons you mention are valid reasons to allow an override. (Still, if cookies are used for this or any other purpose, all cookies and their values should be documented, in case the user wishes to adjust them (or copy them) manually, and/or to understand what they are for.) Logout (and the duration that the login data is kept) is the responsibility of the user agent. Unfortunately, none that I know of provide the user any control over that.

mattmanser 6y ago

It was a while ago now but I'm pretty certain that I read some comments here saying using Accept-Language is often a bad idea. From what I remember, your IT department may muck it up, or you're using a shared computer at say a hostel and someone's set it and you don't know how to change it, etc. Aside from that, most of your examples need a lot of foresight, work and knowledge to actually pull off.

zzo38computer 6y ago
That is a valid consideration; it can use the URL to override the Accept-Language header (and the document can also include links for other languages, if appropriate). Likewise, the URL can also be used to override the Accept header.

toast0 6y ago

Accept-language is an okish default, but web pages end up needing to provide overrides because users are not always in control of those values, or the user may have preferences that don't fit the scheme. A cookie is a reasonable place to store the override. Http login is really hard to make user friendly, and has no way to logout in a user friendly way; the user needs to be prompted for a password again and not enter it. An HTML form and cookies just works better.

zzo38computer 6y ago
For languages, yes, overrides could be stored in a cookie, although they could also be stored in the URL (especially for documents intended to be downloaded). It could also support both. The reasons you mention are valid reasons to allow an override. (Still, if cookies are used for this or any other purpose, all cookies and their values should be documented, in case the user wishes to adjust them (or copy them) manually, and/or to understand what they are for.) Logout (and the duration that the login data is kept) is the responsibility of the user agent. Unfortunately, none that I know of provide the user any control over that.