Last modified: 2014-10-16 07:53:35 UTC
Loading http://nl.m.wikipedia.org/wiki/Titanic_(schip) in the iOS simulator shows a very poorly rendered set of info boxes.
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
Started a discussion on wikitech-l list: http://lists.wikimedia.org/pipermail/wikitech-l/2012-April/060224.html
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
Setup the page http://www.mediawiki.org/wiki/Making_MediaWiki_Mobile_Friendly to document these problems.
This seems to be a tracking bug, so I'm adding it as a blocker for bug 2007.
Forgot to link to this > http://www.mediawiki.org/wiki/Deprecating_inline_styles
*** 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.
Captured this as a story: https://mingle.corp.wikimedia.org/projects/mobile/cards/221
Updated mingle stories: https://mingle.corp.wikimedia.org/projects/mobile/cards/222 https://mingle.corp.wikimedia.org/projects/mobile/cards/223
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 .
