Talk:Requests for comment/Allow styling in templates

Is this a good idea? / Would this be useful?

Yes

Raise your hands here:

• +1 Jdlrobson (talk) 18:43, 13 June 2013 (UTC) This would reduce the need for a lot of hacks that currently exist in the MobileFrontend to workaround this problem and usually don't do very well at it.
• +1 CSteipp (talk) 17:28, 19 June 2013 (UTC) In the future, I would like to reach the point where we can have a CSP rule that does not include 'unsafe-inline' for styles. I see this as a first step in that direction.
• Tfinc (talk) 23:56, 22 August 2013 (UTC)
• +1 Cscott (talk) 18:06, 26 August 2013 (UTC)
• +1 --Gqqnb (talk) 06:43, 13 February 2016 (UTC)

No

Wave your angry fists here:

Should this be part of the template itself or a separate template file?

For use of a Style tag

Sign here:

• This allows to include it in conditional #if’s and to be able to dynamically change some values (e.g. width of some elements, etc.). I’m not sure it is really needed and useful and good programming, but I just mention it. ~ Seb35 09:18, 22 July 2013 (UTC) By re-reading it, I think the CSS in this category should not be "dynamic", and must be sanitised (e.g. no <includeonly>, <translate>, or other wikitext-special tags must be here). Even if the sanitisation here is more difficult, it would be more coherent for the template: same history to track the changes, easier exporting (if any central repository of templates), same permissions. ~ Seb35 [^_^] 09:16, 30 December 2013 (UTC)
• Seems more consistent with the current content model and security policy. Separate CSS requires more thorough sanitization of, eg, @import statements, external links, etc. Cscott (talk) 18:07, 26 August 2013 (UTC)

For use of a separate css file

Shout here:

• +1 Jdlrobson (talk) 18:43, 13 June 2013 (UTC) I would personally like to see and implementation this way as it allows us to easily separate the entire css into a separate file in the future and decouples the CSS from the wikitext. Templates are already scary enough as it is without style tags! :)
• +1 S Page (WMF) (talk) 01:50, 3 July 2013 (UTC) Yes I can't see a benefit to a style tag. One file seems simpler at first but separation of concerns makes it easier to work separately. Plus syntax highlighters and checkers can do a better job. It would be great if the CSS file allowed @import so users could pull in kewl CSS, and for super-bonus points if MW could figure out a "What links here" for CSS files based on this (ContentHandler can do anything, right?)
  • Note if LESS does get into core templates could potentially support LESS which should give lots of power :) Jdlrobson (talk) 18:33, 5 September 2013 (UTC)
• +1 We have a beautiful resource loading system. Minification, concatenation, RTL support, etc... It would be nice if template styles could make use of this by being loaded from a separate page (after sanitization). Daniel Friesen (Dantman) (talk) 22:54, 11 September 2013 (UTC)

Who can edit?

Selected trusted group

• +1 I think editing css requires a certain level of trust and knowledge. In a similar way to how we only allow certain editors to edit MediaWiki:Common.css I'd assume the same to apply to template css. Allowing anyone to edit CSS regardless of experience is asking for trouble in my opinion - it's important to keep the frontend of the site as efficient as possible - https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Writing_efficient_CSS. Jdlrobson (talk) 19:21, 13 June 2013 (UTC)

Same permissions as accompanying page (template)

• +1 Both regular templates (ParserFunctions) and ones using Lua require knowledge for many things (though there is still sometimes room to make copy changes without such expertise). Mistakes or bad code can have serious performance ramifications (generally far worse than bad CSS would cause). However, the fact that templates are open by default means new people are capable of gaining this knowledge, and improvements can be made faster. Commonly used templates are already protected on many wikis. Given that templates and their CSS will generally be edited in conjunction, I think we should link the protection, and continue deferring to the community's judgement about which templates should be protected, and at what level. Superm401 - Talk 21:33, 13 June 2013 (UTC)
  • The issues with CSS are not performance related they're security related. Daniel Friesen (Dantman) (talk) 21:57, 13 June 2013 (UTC)

    I agree (although it's both, performance is the lesser consideration). As I said on Wikitech, there needs to be a sanitizer. In addition to that, I've suggested below scoping it to the body to prevent people from trying to style interface elements (the sanitizer is still needed to make sure they don't try absolute positioning tricks, etc.). Superm401 - Talk 22:01, 13 June 2013 (UTC)

• +1 Cscott (talk) 18:08, 26 August 2013 (UTC)
• +1 (and I’m in favour of a <style> inside the template) ~ Seb35 [^_^] 09:21, 30 December 2013 (UTC)

What measures need to be made to take into account performance and security

Please voice any concerns you have here:

• Template css would have to be restricted to a certain audience Jdlrobson (talk) 18:43, 13 June 2013 (UTC)
• Template CSS should be properly sanitized, and scoped to only affect the content. Ideally, it would only affect the output of the template itself, but I'm not sure how to implement that, given that templates can use different element types, some only open a tag, some only close, some do neither, etc. So I suggest scoping it to bodyContent or something narrow (possibly skin-dependent) containing only the body. There should also be an autogenerated comment at the top of the CSS so it's easy to track down what template is responsible for certain code. So if someone writes the below in Template:Columns.css:

@media all and (min-width: 600px) {
        .leftPane { width: 300px; float: left; }
        .rightPane { width: 300px; float: right; }
}

it will be transformed to:

/* CSS from Template:Columns.css Revision 1234 */
@media all and (min-width: 600px) {
        #bodyContent .leftPane { width: 300px; float: left; }
        #bodyContent .rightPane { width: 300px; float: right; }
}

It does lengthen the selectors, and it there could still be leakage to other parts of the content. However, it shouldn't affect interface elements, and the comment (which needs to survive RL) would allow tracking down the offending template pretty easily. Superm401 - Talk 21:57, 13 June 2013 (UTC)

• As mentioned by Tim on Gerrit change 68123, "Sanitizer::checkCss() only validates an individual declaration, there may be new security issues in the validation of entire stylesheets.". So we do need to work out what the css parser would look like, and what would be allowed from an arbitrary blob of css. Possibly use HTMLPurifier's css sanitization? CSteipp (talk) 17:02, 27 August 2013 (UTC)

• Cache: Add the CSS/JS in the templates could fragment the client cache (I not really knowledgeable about this and the way RessourceLoader handles this, I may be wrong). It is probably better for the global load that the CSS/JS of a rarely-used customised template is loaded in a separated page than the global CSS/JS, but on the other side it is better to load the CSS/JS of a frequently-used customised template in the global CSS/JS to avoid loading it in a separated CSS/JS call. Probably the better solution to this is to either have a checkbox to let the user decide if the CSS/JS should be included in the global or "local" CSS/JS, either heuristically determine it given the statistics of use of the template. ~ Seb35 09:46, 22 July 2013 (UTC)

• Tracking of the changes: In comparison with the collect of all CSS rules/JS functions in a global CSS/JS page, such an editing model of the CSS/JS would decrease the central management of the CSS/JS done by trusted users (administrators) and this could lead to fears from administrators and regular users (CSS/JS hacks of templates with repercussions on all pages where the template is transcluded). Some listing of the customisations on the templates could help handle the vandalism operated through CSS/JS; this would be quite immediate if the CSS/JS are on a separated associated page (e.g. Template:Name/css) with the possibility of watching the pages and with the "trailer" param in Special:Recentchanges (although it seems it only work on translatewiki with /langcode). ~ Seb35 11:29, 22 July 2013 (UTC) If it is chosen to have <style> tag instead of a separated page, <style>-customised templates could be added in a category in order to follow these with Recentchangeslinked. ~ Seb35 [^_^] 09:35, 30 December 2013 (UTC)

1. bodyContent is skin-specific. Use #mw-content-text. Daniel Friesen (Dantman) (talk) 22:41, 11 September 2013 (UTC)

• Ideally, if template CSS is in a separate .css file, it should be served through ResourceLoader (as 'template.' modules), and use its caching scheme. This should trigger no page change as opposed to when inline CSS is changed inside templates, which potentially saves cache misses. — Edokter (talk) — 11:01, 26 March 2014 (UTC)

JavaScript

The RFC focused here on CSS could also be easily extended to the JavaScript associated with some templates (collapsible tables, fr:Template:Images, fr:Template:Titre incorrect, en:Template:Link FA, etc.). Possibly the response is different (security mainly) but the general problem is the same. ~ Seb35 10:02, 22 July 2013 (UTC)

Consistency

This would add a bit of consistency in the tracking of the changes of a specific template (no need to check the Common.js/css in addition of the template page), would ease the copy of the templates accross wikis and would be in the good direction in a global future goal of sharing some templates accross a set of wikis. ~ Seb35 10:38, 22 July 2013 (UTC)

Scoped CSS

I think this could be implemented by simply implementing the scoped CSS extension (using polyfills for older browsers, such as https://github.com/PM5544/scoped-polyfill). Unbalanced templates would allow the CSS to 'leak', but not out of the content area, and that's no different from any of the other things unbalanced templates can do. It's an orthogonal issue. Cscott (talk) 18:10, 26 August 2013 (UTC)

I should note that simply using scoped css alone won't prevent css from applying to stuff outside of the scope if someone malicious wants it to. Even with a polyfil to handle browsers that don't support scoped css tags the standard for scoped css permits rules prefixed with @global to apply outside the scope. Daniel Friesen (Dantman) (talk) 22:51, 11 September 2013 (UTC)

Just an example of a legitimate use of a non-scoped style: {{en:Link FA}}. If non-scoped styles are allowed and if {{{1}}} is allowed in <style>, it could be rewritten without JavaScript:

<style>

.interwiki-{{{1}}} { list-style-image:url(...); }

</style>

(but I guess these two security implications are too strong to be permitted). ~ Seb35 [^_^] 10:55, 30 December 2013 (UTC)

Bugzilla

This also seems to be bug 35704. Discussion should probably happen here, I'm just pointing out the link. Cscott (talk) 18:13, 26 August 2013 (UTC)

Class-triggered CSS includes

An alternative idea is to use CSS classes with a mediawiki-specific prefix (mw-* for example) for content styling. Based on those prefixed classes, CSS fragments can be pulled from a CSS namespace (mw-foo -> CSS:foo), and assembled into a block of CSS in the head. Multiple rules and media selectors can be defined for each class-triggered CSS include. Scoping can be enforced by prefixing each rule with the class selector (.mw-foo). The assembly of the content CSS should be done in alphabetical order to ensure deterministic precedence.

Advantages:

• works for both page and template content
• no issues with unbalanced transclusions
• shared definitions for small network transfers
• no immediate need for scoped style element support in the browser

Performance should be good if the list of classes and possibly the CSS itself is generated on save. Similar to template links, pages using a class should probably be tracked with a classlinks table, so that caches can be updated and the consequences of a potential edit can be considered. -- Gabriel Wicke (GWicke) (talk) 00:01, 13 September 2013 (UTC)

mw- is reserved for core and extension code, so we would need a different prefix. Beyond that, this is interesting, but there are limitations. It's not obvious how to do something (or where it should go) like:

@media all and (max-width: 699px) {
  .some-navbox .columns {
    column-count: 1;
  }
}

-- Superm401 - Talk 22:58, 16 September 2013 (UTC)

The media query should work as expected when placed in CSS:some-navbox. That page's full CSS content including the media query would be included whenever class="mwc-some-navbox" (assuming a prefix of mwc) is encountered. Can you describe the potential issue you see? -- Gabriel Wicke (GWicke) (talk) 05:35, 17 September 2013 (UTC)

This is definitely interesting and much more flexible than my original suggestion. The thing I like most about it is that it allows sharing of stylesheets across templates which is even better. How would I register a stylesheet would it be {{include:Foo.css}} or would it simply deduce them from the classes present? Jdlrobson (talk) 18:36, 4 December 2013 (UTC)

Using a class with the specific prefix in content would trigger the inclusion. To make this efficient the list of used content classes would be saved in separate metadata at parse time. -- Gabriel Wicke (GWicke) (talk) 23:50, 4 December 2013 (UTC)

I like this use of the classes to resolve the problem of multiple templates on a page; it appears to be the good solution for it.

About the creation of [[CSS:Foo]] it seems to be a return to commonly-used styles, not very far from the current [[MediaWiki:Common.css]] or to be more precise to the [[MediaWiki:Content.css]] proposed in Thread:Talk:Requests for comment/Scoping site CSS/No.. To decide on the granularity we want to allow to the template styles, I find we should obtain more statistics about the current usages by classifying "the styles versus the templates". There are two extreme scenarios: 1/ there is a lot of styles which are used only in an associated template, or 2/ a lot of styles are used in a variety of templates. If the former is more frequent, it makes sense to associate a style to each template; if the latter is more frequent, it makes sense to create set of styles in shared pages (CSS:Foo).

Anyway, there exists MediaWiki:Common.css (and possibly MediaWiki:Content.css) which should be used in edge cases (non-template styles, frequent styles, non-scoped styles (e.g. {{en:Link FA}}), etc.). ~ Seb35 [^_^] 10:35, 30 December 2013 (UTC)

Publicity of this RFC

I left a message about this RFC on the French-speaking Wikipedia (Wikiproject templates): fr:Discussion Projet:Modèle#RFC « styles dans les modèles » (permalink). It’s entirely in French for non-English-speakers and it is a summary of the key questions of the RFC and the talk page. I will try to translate the responses if needed, but if I forget you have here the link. Perhaps somebody could add a similar small message in the technical Village Pump of enwiki? (I’m not a regular user of this one.) ~ Seb35 [^_^] 11:43, 30 December 2013 (UTC)

I'd add some messages if only I could understand and explain the RfC. :) See #Use case and #Readability. --Nemo 13:01, 9 October 2014 (UTC)

Discussion at Architecture Summit, & RFC meeting this week

Per the discussion at the January 2014 architecture summit, by about the beginning of April 2014, folks would like to see a prototype. Would it be possible for us to talk about it or see progress at this week's RFC review meeting? Thanks. Sharihareswara (WMF) (talk) 05:47, 26 February 2014 (UTC)

RFC meeting March 26

We plan on discussing this RFC on March 26th at an IRC architecture meeting. Onwiki comments are of course welcome in the interim! Sharihareswara (WMF) (talk) 22:32, 10 March 2014 (UTC)

Use case

This RfC really needs a stronger use case than one user page of one user on a fishbowl wiki. :) The biggest use cases I'm aware of are Extension:Collection (see bugzilla:48052) and Kiwix (which uses the "noprint" class IIRC, the same as action=print?) but there is also "nomobile" class if I remember correctly and you surely can think of better examples before the next meeting starts. --Nemo 08:28, 25 March 2014 (UTC)

+1. Sorry, I noticed the same thing again and came here to say what above. This RfC will look simply ridiculous and childish as long as its benefits are exemplified as "let's make one use page look prettier". There are tens of thousands templates across Wikipedias which had to embed specific classes or categories for the sake of offline consumption... surely you can fine ONE to make the case of this RfC. Thanks, Nemo 12:58, 9 October 2014 (UTC)

Readability

I have to read each sentence in this page three times to understand them. Frankly I gave up after the first one. --Nemo 08:28, 25 March 2014 (UTC)

Need help writing code

Per Architecture meetings/RFC review 2014-03-26, Jon would love some help writing the initial code for this. Thanks! Sharihareswara (WMF) (talk) 02:16, 8 April 2014 (UTC)