Drop support in wikitext for inline styles
Open, LowPublic

Description

Inline styles are inherently bad for accessibility, mobile friendliness, and security.

Instead of a series of hacks to try to get around this, with an endless number of subsequent issues, instead let's just stop allowing them.

Note: For Wikimedia production, the TemplateStyles extension would replace the need for inline styles for all templates. This ticket is very far away from implementation, and will not be done before migration of uses to something that retains the abilities for wikis to do this. There is no need to panic. :-)

bzimport set Reference to bz35704.
bzimport added a subscriber: Unknown Object (MLST).
Tfinc created this task.Apr 4 2012, 6:50 PM

Another example of problematic inline styles just like bug 31591
Setting float and width seem to be the cause these issues. We can scrape these out but that will not be very efficient.

bug 36076 is also caused by inline styling (usually how I check this is doing $("*").attr("style", ""); in my browser console window

How feasible in terms of performance would it be to remove all inline styles from an article apart from ones which are marked in a special way e.g. have a class mobile-safe ?

This would allow people to still use them but use them responsibly

bug 36030 is another example of problems caused by this

also see bug 30887

also bug 34878

From the feedback:

Also visiting
http://en.m.wikipedia.org/w/index.php?title=Selfridge_Air_National_Guard_Base#_
shows the dot on the map in Canada

This is due to width:auto !important defined on .thumb .thumbinner[style]

All these bad rules currently have to be overridden in hacks.css via tag[style] css rules
The latest issue we have encountered with this is slowdown in scrolling on iOS 4.x (see bug 36605).

We're yet to find a suitable solution to this problem but we seemed to be getting to the following situation:

  • Allow users to define css rules rather than inline css
  • Clean up templates, possibly allowing flagging of templates to make this job easier
  • In the long term considering the turning off of inline styles on the mobile site

The remaining issue there is XSS and the possibility of damaging ui's (for instance a user could update a css stylesheet to make all content invisible).

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

The licensing section also renders horrible on smaller screens - yet again there are some inline styles with fixed widths of 90px causing this

http://en.m.wikipedia.org/wiki/File:Nikolic_Tomislav.jpeg#section_2

This seems to be a tracking bug, so I'm adding it as a blocker for bug 2007.

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

For this to be solved we need the following things

  1. A mechanism to allow pages to have associated stylesheets where css rules can live
  2. A community activity of migrating inline styles in wiki pages to these stylesheets
  3. Stripping inline styles from the mobile site
  4. At a future date stripping inline style support in wikitext

If anyone has the time to work on this, I will work hard to unblock any obstacles people face.

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.

SamB added a comment.Feb 14 2014, 5:51 PM

(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 .

jeremyb-phone set Security to None.Apr 9 2015, 4:13 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 5 2015, 9:52 PM
Ltrlg added a subscriber: Ltrlg.Nov 6 2015, 5:02 PM
Danny_B moved this task from Unsorted to Inline / obtrusive code on the Accessibility board.
Danny_B added a subscriber: Danny_B.

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

Jdforrester-WMF changed the title from "Deprecate inline styles (tracking)" to "Drop support in wikitext for inline styles".Apr 25 2016, 6:53 PM
Jdforrester-WMF edited projects, added MediaWiki-Page-editing, Epic; removed Tracking.
Jdforrester-WMF edited the task description. (Show Details)
Jdforrester-WMF added a blocked task: Restricted Task.
Jdforrester-WMF removed a subscriber: wikibugs-l-list.

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.

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.

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.

kaldari removed a subscriber: kaldari.Apr 28 2016, 9:38 PM

Add Comment