Support. I like this idea as right now, the lack of settings on desktop mean we have to limit ourselves to the simplest, most conservative user interface (not always the most intuitive) at the expense of adding very helpful features that could be turned off if a minority found it unhelpful.
Topic on Talk:User Interaction Consultation/Preference menu for readers
I like the idea as well (it came up a lot when readers asked for an opt-out from MediaViewer; also a bunch of tools have poor-man's-anon-preferences by remembering last state, such as whether VisualEditor or the wikitext editor was used the last time). There are two technical difficulties with it, though: it splits caches, and preferences stored in the browser cannot be accessed cross-wiki.
Can't the "preferences cookie" be excluded from the caching decision? How is this done for the Visual Editor and Reference Tooltips? Most preferences involve loading or not loading a particular piece of JavaScript and could be done browser-side. Or do you want to completely avoid sending any JS server-side if a particular preference is not enabled?
I'd also imagine that most readers without an account only visit one or two particular language editions of Wikipedia. So having to set preferences at most twice wouldn't be that bothersome.
As long as only client-side code uses the cookie, caches can ignore it. A lot of the current user preferences require server-side processing, though. Skin rendering, thumbnail sizes, PNG vs. MathML images, date formats etc. Some of that could be replaced via advanced browser features (e.g. service workers can rewrite thumbnail dimensions before the browser starts loading them), but not all.
Ah, right. But a lot of the server-side preferences like math rendering and date formatting are not very important for readers. Changing thumbnail size might be a good option for readers, but that could be limited to just "big" and "small" or completely omitted if even that's not technically feasible (I think the last time the community asked the developers to increase the default thumbnail size, this was declined because of bandwidth concerns, so that may be a problem as well).
For readers, stylesheet options (font size/style) and optional features (Visual Editor, Hovercards, Reference Toolstips, Media Viewer, ...) would be the most important preferences, and that can all be done client-side.
@Ruud Koot @Tgr @Nemo bis Just a heads up that we are hoping to move forward with this idea, as it is crucial for rolling out and evaluating many new reading experiences, including hovercards. Here is the consultation where we are asking community members for their input on how we implement this: Beta Feature/Hovercards/preferences I encourage you to add your thoughts. We had a similar consultation around the new mobile language switching button (live in beta) that went really well.