Loading http://nl.m.wikipedia.org/wiki/Titanic_(schip) in the iOS simulator shows a very poorly rendered set of info boxes.
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
From the feedback:
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:
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).
The licensing section also renders horrible on smaller screens - yet again there are some inline styles with fixed widths of 90px causing this
For this to be solved we need the following things
If anyone has the time to work on this, I will work hard to unblock any obstacles people face.
This would allow us to shift styling to stylesheets and allow us to write mobile specific rules.
(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
Though, for clarity, I believe it's HTMLTidy, not includes/Sanitizer.php, that currently catches unclosed <div>s, etc.
(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
care of the HTML issues, it should also be able to ensure that the scope of
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
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:
<style scoped> /* ... */ </style>
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.
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:
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 .