Related URL: https://gerrit.wikimedia.org/r/68123 (Gerrit Change I557f5abd54d73c288c23c00ecc9f568400355d7c)

Opened the RFC https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates

This would allow us to shift styling to stylesheets and allow us to write mobile specific rules.

Note that there is apparently a robust polyfill for the new scoped-CSS proposal, at https://github.com/PM5544/scoped-polyfill .

So we could move forward with just scoped CSS, and add the polyfill to our pages to Make It Work Everywhere. That's one idea, at least.

(In reply to comment #21)

So we could move forward with just scoped CSS, and add the polyfill to our
pages to Make It Work Everywhere. That's one idea, at least.

The problem is unbalanced templates. We could try an approach like my suggestion at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Allow_styling_in_templates#What_measures_need_to_be_made_to_take_into_account_performance_and_security

Or, we could support template styling only for balanced templates. I'm not sure if this is detectable/enforceable, but it might also help Parsoid/VE if there's a way to check it.

I don't think that unbalanced templates are a problem. They would allow the style to leak, but that's no different from how unbalanced templates can currently open/close unbalanced tags, etc. We already have a sanitizer to take care of the HTML issues, it should also be able to ensure that the scope of the template doesn't escape out of the content area.

(In reply to comment #23)

We already have a sanitizer to take care of the HTML issues, it should also be
able to ensure that the scope of the template doesn't escape out of the
content area.

Indeed.

Though, for clarity, I believe it's HTMLTidy, not includes/Sanitizer.php, that currently catches unclosed <div>s, etc.

• Bug 53866 has been marked as a duplicate of this bug. ***

(In reply to comment #23)

I don't think that unbalanced templates are a problem. They would allow the
style to leak, but that's no different from how unbalanced templates can
currently open/close unbalanced tags, etc. We already have a sanitizer to
take
care of the HTML issues, it should also be able to ensure that the scope of
the
template doesn't escape out of the content area.

The sanitizer knows nothing about nesting. Style elements need to be wrapped around a subtree, which is where you run into trouble if your template output is not a subtree.

Parsoid infers and encapsulates DOM subtrees affected by one or more templates. Scoped styles could piggy-back on this information, but then you still have to solve the issue of merging styles from multiple templates in a way that hopefully resembles the author's intentions.

(In reply to comment #22)

The problem is unbalanced templates. We could try an approach like my
suggestion at
https://www.mediawiki.org/wiki/Talk:Requests_for_comment/
Allow_styling_in_templates#What_measures_need_to_be_made_to_take_into_account
_performance_and_security

Jon and I talked about this for a while. We didn't reach conclusions, but he pointed out you could use <style scoped> purely around bodyContent:

<div id="bodyContent">

<style scoped>
  /* ... */
</style>

</div>

This would be an alternative to the CSS rewriting idea at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Allow_styling_in_templates#What_measures_need_to_be_made_to_take_into_account_performance_and_security .

This dodges the unbalanced template issue, while still preventing styles from leaking into the chrome (non-content) areas. However, it does nothing to attempt to prevent templates from interfering with each other.

However, I found a general issue with <style scoped> while reading about it (http://html5doctor.com/the-scoped-attribute/#compatibility). Since old browsers will simply drop the scoped, they will treat it as a regular style, meaning there's no scoping.

It seems like this can be avoided with polyfills in at least some browsers (e.g. https://gist.github.com/richtr/4039383 works for me), but if JavaScript is disabled (and possibly for old browsers), it falls back to being global CSS.

There is a proposal for a <scopedstyle> tag that may mitigate this.

I added an alternative proposal at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Allow_styling_in_templates#Class-triggered_CSS_includes

Gist: Compile CSS definitions from a CSS namespace whenever matching prefixed classes are used in the content.

(Note: This looks like it has changed from being a tracking bug to discussing what a wikitext version of "<style scoped>" should look like, and how to implement it. Also, it doesn't look very mobile-specific anymore to me.)

Personally, I think the simplest approach would be:

1. Use basically the same syntax as HTML5 does in the wikitext, only without the first-child restriction.
2. *Do* preprocess the style text, I can imagine some rather neat parameterized templates. (Catching runaway tags in the page content is important, of course, but I'm fairly certain this was already the case?)
3. *Don't* try to do anything complicated to restrict the effects to the output of one template; it sounds like a lot of work only to make the feature *less* useful.
4. Transform the pre-processed scoped CSS in the input into non-scoped CSS in the output (by generating a class name for each unique scoped stylesheet, adding that class to the relevant nodes, and appropriately prefixing each selector), because only Mozilla appears to support the feature by default, JS-based polyfill only works when JS is on, and you need to sanitize the CSS anyway.

I agree this is not really a MobileFrontend bug anymore. This was discussed at the architecture summit. See https://www.mediawiki.org/wiki/Architecture_Summit_2014/UI_styling and https://www.mediawiki.org/wiki/Talk:Architecture_Summit_2014/UI_styling .

Related: T483: RfC: Allow styling in templates.

I'm going to re-purpose this task per the children.

Will adding colors text require use of TemplateStyles then? Some inline style like adding color or change font will not really introduce problems to mobile friendliness and security, why not support both inline styles and TemplateStyles? These could share a codebase for parsing and sanitizing.

In T37704#2236621, @Nbdd0121 wrote:

Will adding colors text require use of TemplateStyles then?

Yes.

Some inline style like adding color or change font will not really introduce problems to mobile friendliness and security,

Because of the third objective (which you skipped), accessibility.

why not support both inline styles and TemplateStyles? These could share a codebase for parsing and sanitizing.

TemplateStyles are scoped to the template rather than apply globally.

It can be a great overhead for adding style tags instead of inline styles, if the style is used extensively in a page (this is the case for many fan-wikis, some of them contain a lot of colored texts).

Scoped styles, until all browsers supported by MediaWiki natively support that, will need to be shimmed by adding generated classes. This will certainly introduce many classes which will make output ugly and probably causing performance problems as well.

<style>.scope-xxxxxx{color: red;}</style><span class="scope-xxxxxx"></span>
<span style="color:red;"></span>

Which one is preferred? I use color here, which, as you suggested, could bring problems to accessibility, but I do not see accessibility problems in font change, though.

My last argument: this is a super breaking change. MediaWiki is used by other sites as well, not only Wikimedia sites, and these sites might not have much maintainers as Wikipedia to deal with this breaking change. This could simply lead them to stop upgrading MediaWiki software. While I understand the goals, I believe these two ways to deal with styles should coexist, at least an option should be provided to make inline styles still available in future release.

This would remove the ability for dynamic styling (unless parser functions work inside <TemplateStyles>, but that is a coding nightmare), so that is a definite no for me. As @Nbdd0121 says, this is a super-breaking change, and wihtout a good rationale. Both inline and <style> have their uses, and neither has the full set of features that the other lacks.

What is the benefit of using TemplateStyles over inline styles if we're just moving styles from one to another? I don't see it addressing accessibility, mobile friendliness, nor security, because you can do basically the same (but maybe harder):

• accessibility: TemplateStyles still let you define white text over white background
• mobile friendliness: You can now use media queries, that's an improvement, but you can still define the same fixed widths etc breaking mobile
• security: unless a content review system is placed, I don't see any improvement here

TemplateStyles and inline styles can co-exist perfectly, and moving to TemplateStyles seems like a natural move, but it shouldn't be a requirement to disable inline styles IMHO.

In T37704#2236736, @Nbdd0121 wrote:

It can be a great overhead for adding style tags instead of inline styles, if the style is used extensively in a page (this is the case for many fan-wikis, some of them contain a lot of colored texts).

Sure. However, that's what we have ResourceLoader for; the CSS will get massively compressed.

Scoped styles, until all browsers supported by MediaWiki natively support that, will need to be shimmed by adding generated classes. This will certainly introduce many classes which will make output ugly and probably causing performance problems as well.

<style>.scope-xxxxxx{color: red;}</style><span class="scope-xxxxxx"></span>
<span style="color:red;"></span>

That's correct.

Which one is preferred? I use color here, which, as you suggested, could bring problems to accessibility, but I do not see accessibility problems in font change, though.

The important comparison, however, is between {{text-colour-red|Foo}} and <span style="color:red;">Foo</span>. The former is trivially more consistent with the rest of the wikitext language, and much less subject to typo-based semi-working status.

My last argument: this is a super breaking change. MediaWiki is used by other sites as well, not only Wikimedia sites, and these sites might not have much maintainers as Wikipedia to deal with this breaking change. This could simply lead them to stop upgrading MediaWiki software. While I understand the goals, I believe these two ways to deal with styles should coexist, at least an option should be provided to make inline styles still available in future release.

Yes, I know, this will be a large breaking change for MediaWiki 1.30 or so. Making it a default-off option for a version or two is possible, yes.

@Jdforrester-WMF Ain't this now sort of dupe to T89134: Removing inline CSS/JS from MediaWiki? If not then one is obviously blocker to another...

We should deprecate before decommissioning existing wikitext feature, and have a clear support & timeline for decommissioning it.

While TemplateStyles may be a useful addition with regard to templates, it would make simple ones complex, and would not address custom signatures.
In short, this task is about making the editors' life harder in a way that is hardly justifiable by any alleged benefit, and something that not a single community has asked for.

TemplateStyles cannot fix reasonably the case of substed templates.

I want to address another reason against this proposal.

Currently, many mobile sites are moving to a new de-facto standard to provide an AMP view (see https://amp.dev/) which gives a big performance improvement by limiting the set of features that you can use and some styles. But oh surprise! It doesn't limit the use of inline styles. One big problem of styles loaded through a stylesheet is that they either block the rendering of the page, or cause a reflow, being both bad for performance. And for example, one of the things that you should do when defining elements in AMP is to give them a defined size. That's impractical with css stylesheets, where one would need to implement a lot of CSS classes for each specific style on the page.

Inline styles could be limited removing things like backgrounds or colors, but other styles like floats, width, height, paddings and margins should stay.

Is there any RFC page where we could list the pros and cons of this proposal to prevent them being buried/ignored from the big list of comments of this task?

In T37704#5829014, @Ciencia_Al_Poder wrote:

One big problem of styles loaded through a stylesheet is that they either block the rendering of the page, or cause a reflow, being both bad for performance.

This is only partly true. The HTML gives you the freedom to make these mistakes, and since there are a lot of developers out there (and tight deadlines etc), many people cannot handle that freedom. AMP therefore takes away this freedom so that you do not have to worry (at all levels) about making the mistake. On MediaWiki and Wikipedia, the only parts with this freedom and making these mistakes are gadgets (possible to fix if you know how) and userscripts (harder to fix). Core modules and software components are all required to take this into account (it's a big part of the performance work that happened between 2016 and 2018) and actively performance monitored.

And for example, one of the things that you should do when defining elements in AMP is to give them a defined size. That's impractical with css stylesheets, where one would need to implement a lot of CSS classes for each specific style on the page.

Less hard than you think. OOUI for instance already does this and provides tools to do this to developers, and the parser always inserts defined sizing where needed (with a few exceptions, like in the thumbnail frame. I suspect that the parser too will eventually move to being able to generate class names to provide styles for this case as well).

Also note that this ticket is only about inline styles. Style tags (used by TemplateStyles and different from stylesheets) would still be used. What this really is about however, is allowing CSS generated by unprivileged users (via inline styling in wikicode) that is impossible to anticipate the impact of and even to be properly overridden by CSS provided by privileged-users/the software by design.

As you can see, this ticket has been open since 2012. Our views on this have evolved and we are still far from reaching this goal 8 years on. It is also likely that we will stop allowing some style rules before others (in wikicode) before they ever are completely disabled.
But the general design principal behind this ticket stands. Inline styles are bad and having arbitrary audiences being able to use them to override your system defined styling is even worse.

In T37704#5829014, @Ciencia_Al_Poder wrote:

Inline styles could be limited removing things like backgrounds or colors, but other styles like floats, width, height, paddings and margins should stay.

That's a good point. For theming only *-color styles (background, border, box-, text-shadow) has to be refactored to classes, as in Colors.css of WikiVersity.

Some basic layout styles could and should be refactored to the initially loaded css though. Floats, for example, can't adapt to writing direction. Should there be global templates, those have to work in both directions, which is possible by styling a class.

Going further, the inline positioning (padding, margin, etc.) I've seen in wikitext so far is very repetitive, there aren't many different cases. The most common usages should be moved to the base stylesheet to save space in the html.
A very common example: each userbox on enwiki has ca. 600 bytes of markup

<div class="wikipediauserbox" style="float:left;border:1px solid #8888aa;margin:1px;width:238px">
<table role="presentation" style="border-collapse:collapse;width:238px;margin-bottom:0;margin-top:0;background:#DFD"><tbody><tr>
<td style="border:0;width:45px;height:45px;background:lightskyblue;text-align:center;font-size:14pt;font-weight:bold;color:black;padding:0 1px 0 0;line-height:1.25em;vertical-align:middle">
...
</td>
<td style="border:0;text-align:left;font-size:8pt;padding:0 4px 0 4px;height:45px;line-height:1.25em;color:black;vertical-align:middle">
...
</td>
</tr></tbody></table></div>

that can be replaced with ca. 80 bytes:

<div class="wikipediauserbox">
<div class="logo">
...
</div>
<div>
...
</div>
</div>

Repeating that 600 bytes is a waste.

Is there any RFC page where we could list the pros and cons of this proposal to prevent them being buried/ignored from the big list of comments of this task?

I think this task was approached from the wrong angle and I intend to make a new RfC sometime. The title "Drop support in wikitext for inline styles" predetermined the rejection. It's practically impossible to drop that support without changing possibly - now - 6 million pages. That's not the purpose.

For accessibility, theming and html compactness the similar custom inline styles should be unified and systematically replaced with css classes. That's the real deal: it would be a years-long project.
Imho this should be titled "Long-term: Replace inline styles in wikitext with css class declarations, move the layout to the base stylesheet, color definitions to Common.css/Colors.css"

In T37704#5829088, @TheDJ wrote:

As you can see, this ticket has been open since 2012. Our views on this have evolved and we are still far from reaching this goal 8 years on. It is also likely that we will stop allowing some style rules before others (in wikicode) before they ever are completely disabled.
But the general design principal behind this ticket stands. Inline styles are bad and having arbitrary audiences being able to use them to override your system defined styling is even worse.

@TheDJ: Is there any research (database query) that tells us what percentage of pages use inline styles? (My guess is between 50% and 100%)
Whatever that metric is, it's millions of pages. Replacing inline styles will be a many-year project, I assume. The most common copied styles can be replaced by bots or AWB, but there will be many unique cases that require a community effort.

Imo, a starting step to this project would be to establish best practices regarding class name allocation, .css stylesheet organization like the modularized Commons.css on WikiVersity,
collecting the most common classes and incorporating them into the skins' css. When the most common styles found their place in stylesheets, that would serve as examples for guidelines written for the community about how to transition to using classes and bots could start migrating the wikitext.
I wonder how this thought fits in with your vision about this process.

In T37704#5829140, @AronManning wrote:

@TheDJ: Is there any research (database query) that tells us what percentage of pages use inline styles? (My guess is between 50% and 100%)

That is likely 100% indeed.

Imo, a starting step to this project would be to establish best practices regarding class name allocation, .css stylesheet organization like the modularized Commons.css on WikiVersity,
collecting the most common classes and incorporating them into the skins' css. When the most common styles found their place in stylesheets, that would serve as examples for guidelines written for the community about how to transition to using classes and bots could start migrating the wikitext.
I wonder how this thought fits in with your vision about this process.

Some best practices are:

1. Don't put a lot of stuff into Common.css (directly or indirectly) because it gets distributed to every single request, even though most pages and people don't need 80% of the CSS rules they are downloading.
2. Use template styles instead of Common.css, for styling content (especially when generated by a template)
3. Outright remove CSS that is no longer needed (like pretty table [now wikitable class]).
4. Use classes, never IDs
5. Don't reuse classnames that have special meaning (using infobox for things that are not inboxes)
6. Avoid tables
7. Use flex and grid CSS over float and table css whenever possible
8. Write 'narrow screen' first (aka mobile), then add media queries on top for non-mobile sizes
9. You don't need !important (you need specificity)
10. Use gadgets, not userscripts

And https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis
There are many of such basic rules.. However due to legacy, not all of these are easily deployable without breaking existing things. However, maybe I should spent some time documenting all of that a bit more expansively on mediawiki.org

But a page like the main page of mediawiki.org demonstrates quite well how to style a page and/or templates https://www.mediawiki.org/wiki/Template:Main_page/styles.css and English Wikipedia has many templates converted to TemplateStyles (but also many important ones not yet).

Thank you for the very detailed answer! It would be great to make this into a document on wiki, I would be happy to contribute to it as well.

As coauthor of this RFC/bug back in the day I want to be clear that Tomasz and I wanted to block use of the style attribute not inline styles in style tags (the distinction is important). It was raised alongside T483 with the vision of a future where CSS was restricted to certain wiki pages (e.g. templates) rather than every single wiki page to support UI consistency and better mobile styling. I think many people misunderstood what was trying to be achieved here (some interpreted it as not allowing editors to write CSS at all) but the idea was that inline styles littered across webpages make it impossible to make general solutions for mobile which is why MobileFrontend exists and should be discouraged. I imagined this would be something like `wgAllowStyleAttributesInWikiText = false```. Note for 3rd party wikis which do not make use of HTML wikitext, I should note there may be a little advantage. As for someone on the frontlines, I estimate I deal with 2-3 bug reports about mobile content every month due to issues with template styles - see Local-Wiki-Template-And-Gadget-Issues for some example.

Is there any RFC page where we could list the pros and cons of this proposal to prevent them being buried/ignored from the big list of comments of this task?

The issues with style attributes are as follows:

1. Impossible to use media queries - can break mobile display
2. Make wikitext look like code that if edited might break something which may be off putting to some potential editors (I'm pretty sure we have research confirming this)
3. They encourage UI inconsistency across the site e.g. blue buttons and yellow buttons and green buttons!)
4. Not possible to watchlist CSS changes across the site - something that people like myself could monitor and share knowledge better.

Pros of dropping style attribute support in wikitext in a complicated wiki like Wikipedia:

• Allows collaboration on styles by experts.
• Potential to restrict interface editing to trusted individuals (separation of concerns)
• Discourages cargo cult programming of bad coding conventions.
• Improves consistency of UI by encouraging sharing of templates across pages
• Improve support for mobile by allowing use of media queries in a shared template
• Can easily watch CSS changes (e.g template namespace articles suffixed with ".css".

Cons:

• For simple use cases editors now have to create a template (we could namespace restrict this to mitigate)
• It's change and it's taking away some functionality. Requires an investment in community outreach to ensure there is mutual understanding between developers and end users about the motivation and the perceived benefits.

Inline styles could be limited removing things like backgrounds or colors, but other styles like floats, width, height, paddings and margins should stay.

The issue with allowing inline styles for background and colors is that it can lead to UI inconsistencies (e.g. some infoboxes have baby blue headings and other infoboxes with navy blue and no clear reason why) and accessibility problems (e.g. foreground/background combinations may not be readable to some individuals with visual empairments).

To be blunt, there is really no reason to use style attributes on Wikimedia wikis anymore except convenience factor and to support legacy interfaces and their use holds us back in our mobile interface and we've outgrown the need for them on our bigger wikis. While they are useful for quick hacks on a user page, we should be guiding editors to collaborate on shared and generic stylesheets to share the burden of the problems that inline styles cause.

The right time to replace hardcoded inline styles in wikitext and templates is if and when Global templates are implemented.

While I agree that GlobalTemplates would be helpful, I don't think this should block this. Even before global templates, there is a lot of benefit to moving styles into template styles (and I'd say that's a precursor of switching to a global template anyway!) There is also a lot of work to be done. I see no reason why steps on this RFC couldn't be made now, given we have TemplateStyles.

In T37704#5833304, @Jdlrobson wrote:

As coauthor of this RFC/bug back in the day I want to be clear that Tomasz and I wanted to block use of the style attribute not inline styles in style tags (the distinction is important).

To clarify this what I meant, too. The usage of inline style attributes <div style="background: ...; color: ...; float: ...; etc.">, not the use of inline style elements <style>.somehighlight { background: ...; }</style>.

Cons:

• For simple use cases editors now have to create a template (we could namespace restrict this to mitigate)

The most common case I've met (not an extensive research...) for which today we use hardcoded (inline) style attributes is highlighting text sections with a border and/or background using the <div> element. This can be easily replaced with the class attribute. The classes need to define the layout (border-width, padding, margin) and colors (border-color, box-shadow, background-color, color, text-shadow). The skins or Common.css (and its subpages) should include a few standard classes (info, warning, error, floats, icons) for layout and colors, that satisfy most simple use-cases, thereby avoiding the need to create templates and burdening editors.

Inline styles could be limited removing things like backgrounds or colors, but other styles like floats, width, height, paddings and margins should stay.

The issue with allowing inline styles for background and colors is that it can lead to UI inconsistencies (e.g. some infoboxes have baby blue headings and other infoboxes with navy blue and no clear reason why) and accessibility problems (e.g. foreground/background combinations may not be readable to some individuals with visual empairments).

In the themes that I've been working on for quite a few weeks there are 115 !important rules to override inline style attributes (template styles are overridden with specificity), although I have just skimmed the wikis, theming a few dozen pages only. It is very tedious (time-consuming) to find and collect these rules and 100% completion will never be achievable.
Those rules have attribute selectors like div[style*="background"], which is very inefficient compared to the indexed class lookup. Any custom inline style that's not added results in dark-on-dark (unreadable) text or occasionally bright-on-bright.
The result is good looking and usable, but it can never be production-ready. In comparison the inversion based solution of Volker E. is always readable (as far as I've tested it), but the colors are not fine-tuned for easy viewing: it depends on the individual viewer, which color palette is more suitable.

To be blunt, there is really no reason to use style attributes on Wikimedia wikis anymore except convenience factor and to support legacy interfaces and their use holds us back in our mobile interface and we've outgrown the need for them on our bigger wikis. While they are useful for quick hacks on a user page, we should be guiding editors to collaborate on shared and generic stylesheets to share the burden of the problems that inline styles cause.

Inline style attributes were hacks introduced in the lack of better practices. Presentation tightly coupled to the content is not the future direction to take.

The right time to replace hardcoded inline styles in wikitext and templates is if and when Global templates are implemented.

While I agree that GlobalTemplates would be helpful, I don't think this should block this. Even before global templates, there is a lot of benefit to moving styles into template styles (and I'd say that's a precursor of switching to a global template anyway!) There is also a lot of work to be done. I see no reason why steps on this RFC couldn't be made now, given we have TemplateStyles.

Indeed. Starting locally would refine best practices and prove the concept. Global templates imho is the occasion to bring this task to 100% completion, converting all inline style attributes on all wikis both in wikitext and templates.
I assume these projects will take a few years, thus after Global templates are started (assuming they will be), these projects are best done in unison.

In T37704#5833304, @Jdlrobson wrote:

3. They encourage UI inconsistency across the site e.g. blue buttons and yellow buttons and green buttons!)

Please bring back green buttons. Thanks, T110555.