Extension:TemplateStyles/Q&A

 What is the most convenient way to apply styling to templates?

About and Rationale
The extension TemplateStyles allows CSS styling to be added to templates. This will result in more flexibility in the way templates are visually designed, plus a better adaptability to screen options, i.e. no more garbled templates on mobile devices. By providing a better and more mobile friendly page rendering, we are better able to deliver the sum of all knowledge, in a more refined experience, to all our mobile readers. More info on Phabricator task T155813.

Allowing CSS styling will also make it easier to separate presentation from content. Currently the only means of styling that does not require editing  or similar is using  style attributes, which means styles are intermingled with the content, and tends to result in lots of repetition, because each DOM element needs to be styled directly, while CSS selectors can easily address many elements with one rule. So with style attributes the content becomes hard to read and edit and the design concept is hard to see at a glance. This is problematic for both templates like this and in-article tables like this.

For example, a table with alternating row colors would currently look like this: and for adding a new row the editor will have to juggle the colors around. With TemplateStyles it could look something like and adding new rows becomes trivial.

We need to decide on the best way to add styling to templates. Where the CSS gets stored will basically determine how the extension is being built, so once we decide on this, other architecture decisions are dependent on it, and therefore it will be very inefficient to change our minds and redo all the work again.

Other use cases
Eliminate the need for colgroups and col to style specific columns: Style all links in a page, without repetitive content like so: Instead of : Stuff 12398 Pickhardt

Workflow changes
Adding CSS to existing or new templates can be implemented in two ways. Since the extension is still under development, we would like to get a better understanding of how well these options would fit into the workflow of template editors and patrollers, so we know if one of these is not an option when planning the architecture.

1. Store CSS in template page
The CSS code will be inserted within the parser tags. This is very flexible - template authors can use #tag or Scribunto to include template parameters, fetch CSS from another page, or even generate dynamic CSS code.

2. Store CSS in a separate page
In this option, styling will live in a separate subpage, something like. With this option, restrictions to template styling could be applied (anyone can edit the template, but a certain user right might be required to edit styling, which has more potential for vandalism). It will also be easier to search templates by style (example: find templates with non-mobile-friendly styles) or watch a template for CSS changes only. In the future, when the multi-content revisions project is finished, subpages can be replaced by "slots", virtual subpages which behave as part of the page for purposes of moving, history etc.

Another possibility here would be to load the styles explicitly with a tag, e.g., instead of using a magic subpage.

Rollout plan open questions

 * 1) Shall we target specific, no so heavily used templates as a "test" templates