The fixed header might be fine as default, but hope there will be an easy way to opt out from it (without having to apply user css hacks). On a 13" I really need all the vertical screen space I can get (both articles and discussion pages tend to be long, so vertical space is precious).
- Mentioned In
- T282578: Redesign header bar to include avatars, taglines, and support different modes when fixed or not
- Mentioned Here
- T131803: Options to only use a specific layout/not go bigger - single-column with only dropdown menus, or one sidebar-only
T131991: Implement theme support and add 'winter' and 'night' variants
T231459: Disable max-width on certain non-text pages or by user preference
Skin-specific preferences are totally doable - just add them the same way as any other extension. More of an issue is when/how to display them (only show when skin is even enabled, maybe?), not cluttering up the preferences further, the age-old issue of 'should it even exist', etc.
We may want to figure out what all the potential preferences would be before adding them... or just all them all and clean it up after.
Skin-specific preferences are doable and at least one skin out there has them.
However, there has been a general push against additional preferences for various reasons, including, but not definitely limited to performance (tl,dr: more preferences = more parser cache fragmentation and whatnot). That's why I don't see this happening anytime soon and I'd argue that there really isn't a need for a preference either because we're talking about a rather essential part of the skin — kinda like what the nested navigation menu on the Nimbus skin is, for example. If you really dislike the fixed header, you can use CSS (and/or JS) to get rid of it; that's why user-specific .css and .js pages are a thing — for customizability.
So for our explosion of user settings here, we're potentially looking at:
- checkbox: enable fixed-position header (this)
- select: column-layout T131803
- select: theme T131991
- checkbox: disable max-width for text pages T231459
That's not... too insane, is it? And now that we have a consistent structure for skin preferences they're not so likely to overwhelm there, and we shouldn't need to worry about cache fragmentation since users all kinda... have fragmented output anyway, no?