bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz35704.
Tfinc created this task.Via LegacyApr 4 2012, 6:50 PM
Jdlrobson added a comment.Via ConduitApr 5 2012, 11:09 AM

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.

Jdlrobson added a comment.Via ConduitApr 18 2012, 7:56 PM

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

Jdlrobson added a comment.Via ConduitApr 18 2012, 8:04 PM

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

Jdlrobson added a comment.Via ConduitApr 19 2012, 2:29 PM

bug 36030 is another example of problems caused by this

Jdlrobson added a comment.Via ConduitApr 19 2012, 2:46 PM

also see bug 30887

Jdlrobson added a comment.Via ConduitApr 19 2012, 3:24 PM

also bug 34878

Jdlrobson added a comment.Via ConduitMay 2 2012, 7:45 AM

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]

Jdlrobson added a comment.Via ConduitMay 7 2012, 10:19 PM

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

Jdlrobson added a comment.Via ConduitMay 7 2012, 10:20 PM
  • Bug 36605 has been marked as a duplicate of this bug. ***
Jdlrobson added a comment.Via ConduitMay 7 2012, 10:56 PM

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

Jdlrobson added a comment.Via ConduitJun 3 2012, 9:52 AM

Setup the page http://www.mediawiki.org/wiki/Making_MediaWiki_Mobile_Friendly to document these problems.

He7d3r added a comment.Via ConduitJun 28 2012, 12:44 AM

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

Jdlrobson added a comment.Via ConduitAug 2 2012, 8:41 PM
  • Bug 38833 has been marked as a duplicate of this bug. ***
Jdlrobson added a comment.Via ConduitOct 10 2012, 5:58 PM

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.

gerritbot added a comment.Via ConduitJun 12 2013, 12:38 AM

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

Jdlrobson added a comment.Via ConduitJun 26 2013, 12:23 AM

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.

cscott added a comment.Via ConduitAug 23 2013, 3:30 PM

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.

Mattflaschen added a comment.Via ConduitAug 24 2013, 4:36 AM

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

cscott added a comment.Via ConduitAug 26 2013, 6:11 PM

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.

MZMcBride added a comment.Via ConduitAug 26 2013, 10:20 PM

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

Jdlrobson added a comment.Via ConduitSep 6 2013, 10:30 PM
  • Bug 53866 has been marked as a duplicate of this bug. ***
GWicke added a comment.Via ConduitSep 10 2013, 2:01 AM

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

Mattflaschen added a comment.Via ConduitSep 10 2013, 3:01 AM

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

GWicke added a comment.Via ConduitSep 23 2013, 3:45 PM

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.Via ConduitFeb 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.
Mattflaschen added a comment.Via ConduitFeb 14 2014, 7:05 PM

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 .

Awjrichards removed a subscriber: Awjrichards.Via WebDec 3 2014, 5:44 PM
Ricordisamoa added a subscriber: Ricordisamoa.Via WebDec 17 2014, 9:09 PM
Mattflaschen removed a subscriber: Mattflaschen.Via WebJan 11 2015, 4:41 AM

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.