@Elitre I've tagged this as Community-Relations-Support, for eventual inclusion into a quarter board. I imagine @Tgr + @Anomie (on-wiki documentation), plus @JKatzWMF + @Nirzar (potential presentation), plus all of Reading Infrastructure w/ Comms person will be involved in the outreach effort, but I wanted to get this on your radar per our email.

^ Changed "Multimedia to "Reading Infrastructure" to reflect proper team.

Including @Johan who followed the related conversation before.

@dr0ptp4kt Do you need anything from us (CLs) right now?

@Johan, not yet. Thanks for asking!

@dr0ptp4kt OK, please ping me when you do.

I've written an updated version for the extension page itself at https://www.mediawiki.org/wiki/User:Anomie/Extension:TemplateStyles, waiting for the rewrite to actually be merged before I replace the existing version. Feel free to edit it if edits are needed.

But it sounds like this task (as far as wiki pages go) is more for a https://www.mediawiki.org/wiki/Help:Extension:TemplateStyles (comparable to the help page for ParserFunctions).

Tentatively scheduling this request for Community-Relations-Support (Jul-Sep 2017).

I posted an update at T164927: TemplateStyles style guidance outreach for @Johan that we're getting close to the beta cluster.

@JKatzWMF @Nirzar @Tgr: this ticket here is the one for the style guidance / user-facing documentation / presentations.

FYI, TemplateStyles is now live in Beta Labs. See, for example, https://en.wikipedia.beta.wmflabs.org/wiki/TemplateStylesTest.

@Krinkle, could you elaborate on the performance implications of using TemplateStyles? Once this is deployed to WMF projects, I was considering moving styles for infoboxes (https://sv.wikipedia.org/wiki/MediaWiki:Gadget-infobox.css) and navboxes (https://sv.wikipedia.org/wiki/MediaWiki:Gadget-navbox.css) from gadgets to TemplateStyles, because I don't think it's an admin concern how they look. Would you recommend against that for performance reasons?

I assume that performance-wise, TemplateStyles are good for sparsely used templates, but bad for widely used templates. Is that assumption correct?

Also, when prepending <templatestyles src="..." /> to a template on its own line, do I need to worry about an extra line break added to the beginning of the template?

In T164879#3377392, @Nirmos wrote:

I assume that performance-wise, TemplateStyles are good for sparsely used templates, but bad for widely used templates. Is that assumption correct?

If by "widely used" you mean "almost every page has it" then yes, but I doubt there are many templates meeting that definition. For more realistic cases, not sure. We'll probably learn more about that once we see TemplateStyles in action.

In T164879#3399399, @Nirmos wrote:

Also, when prepending <templatestyles src="..." /> to a template on its own line, do I need to worry about an extra line break added to the beginning of the template?

I believe so. The parser has special handling for line breaks after comments and inside {{#function}}-constructs but as far as I can see there is no such special casing for extension tags.
(The current implementation definitely adds line breaks; there will be some changes later on in how the parser handles <templatetstyles> tags though.)

@Anomie @Tgr First off, thanks for the great work! :)
Have you considered to and if so, what options would we have to make template styles following CSS coding conventions? I guess one of the thoughts behind was to keep hurdles for template editors low to participate and orientate on lax CSS standard.
Maybe as automated step in sanitizing the files?

When comparing

• https://www.mediawiki.org/wiki/Template:Stylish/styles.css and
• https://wikitech.wikimedia.org/wiki/Template:Portal_list_item/styles.css

one can already see style differences that make it harder to read/skim through the rules. Something which we we're taming in our products' codebases with grunt-stylelint and style-config-wikimedia.

The sanitizer doesn't support imposing a specific coding convention, unless that convention is "minified" which is not a convention friendly for editing. ;)

To do what you ask, we'd need a CSS prettifier to enforce the coding conventions, and we'd need that prettifier to be installed (probably via composer) and run from PHP on save. Then keep in mind that major transformations might confuse users if done at the wrong time during the edit process. Feel free to file a wishlist task for all that and then try to get someone (i.e. not me) interested in working on it, but let's not clutter this task with discussion of it.

Wikitext entered by the user should not be changed silently, for the same reason that fixing style errors in a git hook is a bad idea. It should also not be rejected since we want to evolve our style standards over time but do not want formerly valid templates to become unsaveable. So the right solution is to show warnings in the code editor (preferably via checks run on the client side, for performance, simplicity, and because we already use stylelint which is written in JS). Filed T171128: Warn about violations of Wikimedia CSS code styles in wiki CSS editor.

This task is still unassigned. If there's anything for CLs here, maybe scope better and assign subtasks instead? TY.

Our work is being tracked on other tasks, hence removing the tag here.