Requests for comment/Deprecating inline styles
| Deprecating inline styles | |
|---|---|
| Component | General |
| Creation date | |
| Author(s) | Jon Robson |
| Document status | stalled See Phabricator. |
Please see the related RFC for a suggested and useful first step.
Currently the language MediaWiki uses to author documents allows the inclusion of html elements with style attributes. Mixing layout with content causes various problems with reusability, maintainability and is not future proof. Already on the mobile version of MediaWiki problems are being seen with inline styles with how pages render on smaller screens which could be solved via css3 media queries, however these cannot be done in inline styles. In addition to this the majority of things done in inline styles would be better done as class names for the purpose of consistency. For instance if we have text that is red (where 'red' is being used to serve a warning) this would be better done with a class warning otherwise some text risks being red whilst other text trying to express the same meaning may be a different tone of red (e.g. #BE3B3B)
To take a real example, various pages use inline styles to create two column layouts. Currently to fix portal page layouts we have to edit every page that uses them. A preferred approach would be to make use of stylesheets (either in a style tag or a separate stylesheet) and classes. This would mean that it would only take a change in one wiki page. Additional css rules could also be made to target more specific cases such as print and mobile layouts.
Note it is important to understand that this is the deprecation of inline styles and not styles in general. In a future MediaWiki the following would render a red border
<style>.foo { border: solid 1px red; }</style>
but
<div style="border: solid 1px red;"></div>
would not
Known problematic use of inline styles
[edit]- Two /multi column layouts e.g. portal pages
- There was an interesting (slightly ambiguous) piece of feedback received recently stating that car numbers and names should be in black and white rather than yellow and blues so 'us oldies might be able to keep up'. It sounds like somewhere an article is providing colours in such a way that they are not readable. This is likely to be a problem on desktop as well and reveals how our choices in using inline styles when we edit articles can have a negative effect on our readers.
- Fixed width tables where width is specified in pixels
- Fixed positioned elements (fixed position is problematic on mobile)
- The overall consistency of the site suffers with inline styles. Infoboxes and things that look like infoboxes are a good example. These could have consistent styling if they shared the same class. This helps readers and edits to understand them better.
- Using better markup would allow javascript modules to identify common elements
- Not using inline styles would lead to better organized css and reuse.
Possible solutions
[edit]- Restrict allowed styles to MediaWiki:Common.css
- Allow stylesheets per wiki page
- Allow stylesheets per template page - this allows articles which use templates to share a common stylesheet.
- Allow stylesheets per category - this would allow articles related to the same topic to share a common stylesheet and also help with bugzilla:15075.
- Adapt ResourceLoader so that MediaWiki:Common.css can be marked up with annotations that specify pages that should get certain styles - this means we can have one place for styles yet avoid targeting unnecessary styles at specific pages.
Deprecating inline styles via the mobile site
[edit]The mobile site runs the MobileFrontend extension which includes a beta mode which is activated via the Mobile Settings page.
The mobile site is quite badly effected by inline styles. Various problems are described in Making_MediaWiki_Mobile_Friendly. It is proposed that turning off inline styles on the beta of the mobile site would be a good catalyst for reducing the use of inline styles across the website. The idea being that important and missing styles could be identified and defined in stylesheets, (initially MediaWiki:Common.css but on the long term potentially per page stylesheets. The long term goal would be to remove inline styles altogether in favour of these stylesheets on the main mobile site and then the desktop site. Note on the mobile site this all hinges on bugzilla:34325.
Deprecating inline styles on home pages
[edit]Currently MediaWiki homepages are special cased on mobile to ensure they render correctly. To fix this we should
- set a deadline for a switch over where we stop the special casing on the main page - we can work together during that day to ensure pages are mobile ready 2) we change the code so that a querystring specialcase=no shows what the main page will look like after the switchover
- community works together to move inline styles into a stylesheet e.g. MediaWiki:Common.css and alter homepages
- we turn of the special casing on the deadline date
- deal with broken pages on a case by case basis.
Dissent?
[edit]There are lots of different kinds of inline styles. Many are for color, font size, basic boxes, etc and work just fine.
The sort of styles that are most breakable on mobile are layout styles such as two-column layouts or floats/boxes being given a specific width or margin that doesn't fit well on a mobile screen. In addition, table layouts are often similarly problematic but would not be altered by this proposal, apparently.
What I do support is better ways to specify <style> blocks in a page or template. This allows layout issues to be resolved with CSS media queries when they really really are needed, without cluttering up global styles for things used only in a few places. --brion (talk) 17:46, 2 July 2012 (UTC)
We are in agreement Jdlrobson (talk)
I can sympathise with the desire to replace inline styles with some alternative system that allows media selectors. But I don't think removal of the style attribute from the Sanitizer whitelist is an appropriate way to go about encouraging change, even after a lengthy deprecation period, and even if it is only on the mobile site.
Not all MediaWiki installations care about mobile support. In fact, not all WMF wikis care about mobile support. And some wikis may already have implemented comprehensive mobile support, with inline styles used where they are appropriate for all device types -- removing the style attribute from the whitelist on such a wiki would be a nuisance with no appreciable benefit.
I think deprecation should be implemented solely on the editing side, in an extension which is enabled on the wikis that need it. The extension would display a warning when inline styles are introduced into an article which didn't have them already. The extension could even parse the CSS of the inline styles, and warn only when certain properties such as "float" are used. A tracking category would allow users to deal with existing inline style usage.
Introducing some method for templates and pages to add a style element to a page would be useful. As I said in a comment on https://gerrit.wikimedia.org/r/#/c/68123/ , it's not entirely simple to do so. The simplest way to preserve performance would be to store the styles into the ParserOutput. This could be done by adding a <style/> tag hook, which allows stylesheets to either be specified inline or pulled in from some other page. Security may be non-trivial, especially if resistance to DoS attacks against the browser is desired. -- Tim Starling (talk) 03:40, 12 June 2013 (UTC)
- I would disagree, and say that this is very much a sledgehammer to crack a walnut approach. There is a lot to be said about education of the populace about the issue. Have you tried putting information out through Signpost? Have you looked to develop a page that highlights which sorts of styles are problematic? I believe that some of the mid size wikis, eg. English Wikisource, use inline styles to display the works and do it in a way that does not or should not cause issues for mobile output. Font size variations to replicate the original publication, etc. We work hard to leave right margins floating, to make all of our text coding proportional etc. In fact, I invite you to come to English Wikisource, pull up our pages, and clearly identify to us those pages and those style templates that are problematic as we will clearly wish to address those templates.
That said, it would be great if there was a means to trigger the turning off of styles if that is what the user desires and to have a text only output; somewhat similar to how there is the capacity to turn off certain templates when print output is desired. Hooly dooly, for us to have to define a stylesheet per work would be problematic when we have works being developed in one namespace, and then transcluded and presented in another, especially when you start a work you don't even know which formatting you are going to need to replicate the work. If you can assist us with better solutions, then that would be fantastic, a blanket approach to turning off inline styles is not that solution. — billinghurst sDrewth 13:25, 12 June 2013 (UTC)
I am strongly supporting moving towards media query support and standardized content classes where a style combination is widely used.
From a performance perspective allowing scoped inline style blocks as defined in HTML5 would work if we can implement solid sanitation for such CSS blocks. This would still be compatible with independent template expansion and fragment caching for fast-changing templated content. For very common templates like citations this would however result in a lot of duplicate inline styles which should then be moved out into general content styles instead. Having a set of common content styles also makes it possible to automatically reference those styles from the VE or other user interfaces. --Gabriel Wicke (GWicke) (talk) 16:59, 12 June 2013 (UTC)
- That looks like an interesting feature (link for other people not familiar). It would need a shim for older browsers, right? And I agree scoped inline doesn't make sense for everything. Unless there was an option like the template idea (a stylesheet for a specific template, included once on all pages using it), Common.css or an equivalent will remain important. Superm401 - Talk 01:34, 13 June 2013 (UTC)