Skip to content

Instantly share code, notes, and snippets.

@skizzerz
Last active January 28, 2019 18:41
Show Gist options
  • Save skizzerz/9dac1c8d33a4e44a2b83dc49acdc2c8f to your computer and use it in GitHub Desktop.
Save skizzerz/9dac1c8d33a4e44a2b83dc49acdc2c8f to your computer and use it in GitHub Desktop.
Stuff

Ideas for structure of a revamped skinning system based on Mustache (or insert-other-templating-engine-of-choice)

  • Defined inheritance between skins. Can be multiple levels, but they all chain back to the fallback skin eventually. Templates defined in a child skin completely override templates defined in the parent skin.
  • Use partials/subtemplates/whatever-they're-called to break out bits of the skin into logical chunks. This lets each partial focus on one task, and components using that can be composed easily. Child skins therefore only need to override exactly what they want to change rather than requiring tons of boilerplate stuff.
  • In addition to inheritance with templates (for the generated HTML), provide core LESS files that can be overridden by children skins. Unlike templates, these cascade so children don't need to override everything in the parent.
  • One of the core LESS files should be defining a buttload of variables for everything from color scheme to default padding, and then the other LESS files make use of these variables. The goal is that child skins don't need to re-implement 100% of the CSS from scratch, but they also don't spend tons of effort un-doing things that the parent skin did because they want to be different.
  • In this regard, the fallback skin probably will be largely CSS-free (just what's needed to provide a blank slate for things to customize), and we can provide a base skin used by monobook, vector, and similar which provides a common subset of stuff all of them use. If someone wants to make a vector-derived skin they can then extend that, but if they want to do something crazy they can derive fallback directly and handroll all of their own CSS without having to get into nitpicky style overrides. Best of both worlds.
  • Extensions can hook into the template loading process and extend partials with their own stuff. Usually the extension would create its own partials for custom HTML blocks it needs, and then uses a hook to inject those partial calls into the base template in the appropriate spot. CSS for extension DOM can be provided by ResourceLoader, as is current practice.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment