User:Xover/The Great Header Redesign Project

From Wikisource
Jump to navigation Jump to search

Whys[edit]

  • {{header}} is bulky, unwieldy, and fragile. It has amassed weird, poorly documented, and very specialised behaviour piecemeal over the years. Inductiveload massively cleaned it up during the Covid lull, but it's still got pain points.
  • We have multiple parallel "header" templates with somewhat random reuse vs. cut&paste. {{header}}, {{translation header}}, {{process header}}, {{versions}}, {{disambiguation}}, and so forth. Not all of these should share all code, but at the same time they should share the common fundaments. And they should be clearly distinguished, and optimised for their respective use cases, rather than hampered by the other uses weirdnesses.
  • Dynamic Layouts are interacting badly with headers, and hence preventing further cleanup there. Dynamic Layouts thus need to be part of the scope; and since Dynamic Layouts also need some fairly big improvements we might as well try to tackle both in one fell swoop. Dynamic Layouts are currently more or less stable, robust, and performant—again thanks to Inductiveload's efforts—but they have some annoying limitations and irritating interactions with other moving parts of the site (headers, maint. templates, etc.). It would be extremely good to offload more of its user surface to CSS (vs. JS) and make it cleaner and easier to work with its styles. It also has potential for new layout features that would be nice to explore.

Whats[edit]

  • Experiment with CSS Grid-based dynamic layouts to see if that obviates the need for the awkward DOM manipulation currently needed. It may require the introduction of a manually added {{footer}} to all pages (analogous to how {{header}} is required), but on the upside it may fix all the current problems with dynlayout and enable new stuff.
    • Each layout should essentially be just a .css stylesheet, containing a full definition for a set of standardised classes.
    • There should be a default layout served to all users, which can be overridden either per user or per text.
      • The default layout should be anchored in community consensus so there are no more fights about whether or what {{default layout}} to use
      • In fact, {{default layout}} should just go away (unless there're some edge cases we need to retain it for)
  • Re-enable TemplateStyles in {{header}} and migrate all styling there.
    • This is sort of the flip-side dependency for dynlayouts: we need styling in stylesheets to be able to do proper dynlayouts
  • Start migrating {{header}} and friends into just a single #invoke of Module:Header
    • This is needed not only for cleanup and logical maintainable code, but also for being able to keep state throughout processing, adding tracking cats, and so forth
    • Each distinct header template should get its own entry point so we can keep track of them
    • Some lower level logic should be further abstracted so, e.g. different header templates can use different parameter names for the same concept (or whatever; sharing logic without placing limits on each consumer is the point)
  • Try to figure out a workable "template" system (in the HTML sense) for the header templates (in the MediaWiki sense)
    • As a general problem this needs to be solved upstream, but it may just be workable to co-opt the template system for this. If we're strict enough with the calling context, and police the templates, we should be able to separate structure and layout from the logic.
    • Ideally any admin should be able to tweak the layout templates, and any contributor tweak the sandboxes, without needing to touch or care about the Lua side or the logic
  • MediaWiki:Proofreadpage header template in particular ends up behaving weirdly by being called through PRP, but turning around and calling {{header}}. For one thing, bibliographic fields are fed directly to header's override_ variants instead of one-to-one.
    • Automatic headers' weirdness leads many contributors to dislike them (some even vehemently), even though they are technically speaking a better approach.
    • Automatic headers need special logic, because when PRP is feeding us input we can no longer infer human intent by the presence or absence of a given parameter.
    • But this is metadata and subject to standardisation / house style, so maybe that's a good thing? Or at least an acceptable thing?

Todo[edit]

  1. Pick a text to test Grid-based layouts on (The Green Fairy Book perhaps?)
  2. Create {{footer}} (just an </div> maybe? Or more (<div id="footer"></div></div>) to make generating the footer easier?)
  3. Add {{footer}} to test text
  4. Add support for layout parameter to {{header}}. Trigger for new style layouts during testing/migration; replacement for {{default layout}} on a permanent basis.
  5. Add layout to test text
  6. Disable MediaWiki:Gadget-PageNumbers.js
  7. Figure out whether to serve default default style from site-wide gadget or from pagenumbers-specific gadget
  8. Create a Grid-based default style (based roughly on Layout 2?)
  9. Add support for full-bleed header and footer (and for full-bleed images?)
  10. Figure out how this affects / what to do about maint. templates. Maybe correctly-placed templates don't need no fixing no more?)
  11. Look into whether this gives us new options for placing sidenotes. Probably not since we need to track physical page top and CSS has very little support for tracking / non-nesting relative position. But just maybe…
  12. At some point here we'll need a rewritten PageNumbers.js; and we need to figure out whether to split page numbers and layouts. If we could eliminate the need to calculate pagenumber position using custom code we could maybe even just get rid of pagenumbers code entirely and focus on layouts. If layouts are almost entirely implemented in CSS, we could drop huge chunks of the layout code and focus what remains on UI for picking and switching. Probably not, but one can dream...
  13. Profit?
  14. Get the community to vote on layouts?
  15. Get the community to vote on a default layout?
  16. Is there a sane dark mode implementation here? That is, each layout has a dark mode. Or does dark variants have to be completely separate layouts?