Brion thanks so much for the feedback

A few comments below...

Are more styles damaging or legit? How do we know? I'd encourage keeping all styles by default except for ones known to cause trouble...

The problem is that styles can be extremely damaging render content unreadable. I'd rather have a page that was ugly and readable than a page that is trying to be pretty and unreadable.

This is personally my favourite option and for this reason I'd rather that making content mobile friendly was an additional step. I know this is a big undertaking but as I said readable content should be our priority.

We could also conditionally scrub styles depending on their contents e.g. any styles that contain known problematic properties e.g. width, float, margin for example

Kills backward compatibility with existing pages, so I'd recommend against this.

Agreed.

...

** one could imagine pages/templates being able to maintain their own stylesheets for desktop and mobile to allow customisations

^^^ this would be very useful!

Is that something that has been discussed before and is feasible? It would certainly be useful for mobile as we could apply page specific hacks where needed to fix bugs on the mobile site rather than putting generic rules elsewhere.

Education is tough, but setting good examples in usage and documentation always helps. Most styles are probably cut-n-pasted from elsewhere, so the more we fix, the more new things will be fixed.

An example that I made a little effort on is the layout of portal pages. I manually fixed up a number of portals (but not all! there's more to go), giving them *inline styles* if any that were mobile-safe, and then using *global styles* in MediaWiki:Common.css to provide for multi-column-style layouts on large screens. I also redid some of the templates from using tables to floats or inline-blocks that fit both large and small screens reasonably.

This is true but it is a slow process.

Especially if this can be combined with <script> blocks attached to templates -- and thus not forced to be manually rewritten -- I think that's the way to go.

How would this work? Sorry I'm not sure but I'm not too clear. This doesn't seem to solve the problem for browsers with javascript disabled though..

I think you could use a multi-step process to solve this problem with the help of the community.

1. Detect when inline styles are used on a page and add that page to a list of pages that might have problems being rendered on mobile. 1. Make a special page that displays this list and use an edit hook to reevaluate if a page should be on or off the list each time someone edits it. 2. Possibly display a progress meter on the page 3. This information could be surfaced when someone with sufficient rights to move the styles to a site style sheet loads the editor on that page too. 2. Provide a guide for how to move inline styles into reusable style in the site CSS and how to write special mobile versions of the styles too (using something like MediaWiki:Mobile.css for instance) 3. Set a reasonable timeframe for when the mobile site will begin scrubbing inline CSS from pages 4. Work with the community to reach the goal - as in: don't just dump it on them, listen to their suggestions on what might make it easier for them to make the switch 5. Turn on scrubbing

This might take time, but if it's facilitated like this, it can be accelerated. I think our community will care a lot about mobile access already, but reminding them of how many page views or unique users we have on the mobile site already and inviting them to help make the mobile site even better and more popular would probably help motivate people.

- Trevor

On Fri, Apr 20, 2012 at 11:53 AM, Brion Vibber brion@wikimedia.org wrote:

On Apr 20, 2012 11:30 AM, "Jon Robson" jdlrobson@gmail.com wrote:

...

...

Especially if this can be combined with <script> blocks attached to templates -- and thus not forced to be manually rewritten -- I think

that's

...

...

the way to go.

How would this work? Sorry I'm not sure but I'm not too clear. This doesn't seem to solve the problem for browsers with javascript disabled though..

Sorry meant <style> there!

-- brion

...

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I would like to second what Platonides has said. It's important to understand that 99% of the inline CSS comes from templates. Stripping the CSS is probably not a good option, as the results would be rather unpredictable (some of the templates are heavily dependent on CSS, some are not). Unfortunately, there isn't currently a good solution to this, as the way templates are constructed only allows for inline CSS (without spamming Common.css). My preferred solution would be to start allowing <style> tags within the Template namespace. Then people could create real CSS logic for templates (including mobile styling with CSS queries). There is, however, the slight problem that browser-makers and the W3C don't quite see eye-to-eye on implementing <style> tags in the body. According to the W3C, it is invalid to use <style> in the body unless it is scoped (i.e. uses the scoped attribute). All current browser-makers, however, allow <style> in the body and none of them support the scoped attribute. In other words, we would be pretty much guaranteed to break our W3C validation for almost every page, but as far as I can tell, this is already the case anyway.

Ryan Kaldari

On 4/20/12 1:44 PM, Platonides wrote:

Yesterday, someone asked #wikipedia where was the separation between style and content done on wikipedia. Users don't suddenly start to write CSS rules in the pages themselves. Most inline styles come from templates.

They don't write for a table: border="2" cellpadding="4" cellspacing="0" style="margin: 0.5em 0.5em 0.5em 1em; padding: 0.5em; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; font-size: 95%; but do {{tabla bonita}}

Similarly, the infoboxes CSS don't come from the article content, but from a template two or three layers down.

Fixing 80-90% of the inline styles should be quite simple, as it'll come from a few templates. The problem is to detect *when* that style gives problems on mobile.

I'm not sure what we are trying to mean with it, "it doesn't look right" isn't simple for an algorithm to detect ;) If we need to manually view the page, we could hardly detect it.

OTOH if we are looking for absolute values in that inline, it's simple to do.

So what constructs are problematic for mobile? How to detect them?

Once we have such measures, it shouldn't be hard to go fixing it. Moving css rules from inline styles to site CSS can be a step for fixing the problems (and also recommendable for other reasons), but is not the solution.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

We already don't validate. There's no point to trying to conform to a validator when the spec/validator is wrong. And we already have cases like that. Anyways, technically you could already use scoped anyways. Just add the scoped attribute. Don't use css that applies outside the content area. And then it'll validate, it'll work in browsers, and when browsers actually implement scoped they'll start restricting the scope.

That said I'm not sure about the security standpoint of this. Naturally you have to strip out all expression() and url() sets. Also considering the fact that image() is also being added and that should probably be stripped. You can't html escape <>'s because in HTML <style> is implied to be CDATA; but you also can't leave them alone. And you have to be wary about the fact that trying to blacklist tags may leave potential XSS vectors open. So you'll have to css escape them and hope that works. But after you've dealt with all the XSS issues; you've opened up the ability to completely destroy the UI from within WikiText. In ways even worse than the tricks attempting to simply cover the whole UI with a div. Those tricks being ones you could technically eliminate by using overflow+relative on the content area and disallowing position: fixed; (The only thing in the way of that right now is WP's stupid page icon hack).

My hope was to one day add a proper parser to RL: https://www.mediawiki.org/wiki/Requests_for_comment/ResourceLoader_CSS_Exten...

It would actually understand css. So it could make it completely safe to allow css inside WikiText. Stripping out unknown things that open up holes. And automatically prefixing selectors. It would also cut off the need for ridiculous things like verbosely repeating vendor prefixes or using template hacks. And also allow the use of background-image for files uploaded to the wiki.

On Mon, 23 Apr 2012 14:46:20 -0700, Ryan Kaldari rkaldari@wikimedia.org wrote:

I would like to second what Platonides has said. It's important to understand that 99% of the inline CSS comes from templates. Stripping the CSS is probably not a good option, as the results would be rather unpredictable (some of the templates are heavily dependent on CSS, some are not). Unfortunately, there isn't currently a good solution to this, as the way templates are constructed only allows for inline CSS (without spamming Common.css). My preferred solution would be to start allowing

<style> tags within the Template namespace. Then people could create real CSS logic for templates (including mobile styling with CSS queries). There is, however, the slight problem that browser-makers and the W3C don't quite see eye-to-eye on implementing <style> tags in the body. According to the W3C, it is invalid to use <style> in the body unless it is scoped (i.e. uses the scoped attribute). All current browser-makers, however, allow <style> in the body and none of them support the scoped attribute. In other words, we would be pretty much guaranteed to break our W3C validation for almost every page, but as far as I can tell, this is already the case anyway. Ryan Kaldari On 4/20/12 1:44 PM, Platonides wrote: > Yesterday, someone asked #wikipedia where was the separation between > style and content done on wikipedia. Users don't suddenly start to write > CSS rules in the pages themselves. > Most inline styles come from templates. > > They don't write for a table: > border="2" cellpadding="4" cellspacing="0" style="margin: 0.5em 0.5em > 0.5em 1em; padding: 0.5em; background: #f9f9f9; border: 1px #aaa solid; > border-collapse: collapse; font-size: 95%; > but do {{tabla bonita}} > > Similarly, the infoboxes CSS don't come from the article content, but > from a template two or three layers down. > > Fixing 80-90% of the inline styles should be quite simple, as it'll come > from a few templates. > The problem is to detect *when* that style gives problems on mobile. > > I'm not sure what we are trying to mean with it, "it doesn't look right" > isn't simple for an algorithm to detect ;) > If we need to manually view the page, we could hardly detect it. > > OTOH if we are looking for absolute values in that inline, it's simple > to do. > > So what constructs are problematic for mobile? How to detect them? > > Once we have such measures, it shouldn't be hard to go fixing it. > Moving css rules from inline styles to site CSS can be a step for fixing > the problems (and also recommendable for other reasons), but is not the > solution. > > > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 25 April 2012 12:56, Jon Robson jrobson@wikimedia.org wrote:

...

We already don't validate. There's no point to trying to conform to a validator when the spec/validator is wrong. And we already have cases

like

...

that.

I think we should try to validate though mostly for future proofing...

...

Anyways, technically you could already use scoped anyways. Just add the scoped attribute. Don't use css that applies outside the content area.

And

...

then it'll validate, it'll work in browsers, and when browsers actually implement scoped they'll start restricting the scope.

<snip> > But after you've dealt with all the XSS issues; you've opened up the ability > to completely destroy the UI from within WikiText. In ways even worse than > the tricks attempting to simply cover the whole UI with a div. Those tricks > being ones you could technically eliminate by using overflow+relative on the > content area and disallowing position: fixed; (The only thing in the way of > that right now is WP's stupid page icon hack). > I think if we restricted css to templates that only trusted admins can edit then these problems goes away somewhat no?

"Is wiki admin" doesn't traditionally mean "is fully trusted not to screw

things up deliberately" and *definitely* doesn't mean "is trusted not to screw things up accidentally". It would be pretty easy for an admin to accidentally add styles which screw up the rendering of the edit form and make it difficult to undo. And at least at the moment any such potentially-troublesome edits are confined to one small, low-traffic namespace. Trying to monitor recentchanges to the whole template namespace on a large wiki for XSS is entirely impractical.

--HM

Sorry for the lack of continued discussion on this thread. I've been thinking lots and lots about this over the last weeks and would like to suggest a course of action.

I think we are agreed that the majority of inline styles come from templates and it is the templates we need to fix up.

Trevor earlier suggested a great course of action where we evaluate if pages have problems and fix them up to be mobile friendly. Trevor suggested we should work with the community to reach this goal of moving important inline styles into stylesheets and suggested having a timeframe to do so after which we could scrub all inline styles from the mobile version of the site.

I've also heard that inline styles are highly useful and that since only admins can edit MediaWiki/Common.css it seems unfair to prevent inline styles altogether and also it goes without saying that we are keen to keep backwards compatibility.

So here is my concrete suggestion. I welcome all feedback on this - positive and negative. At this current time this is just a proposal!

1) We turn on inline style scrubbing in the beta of the __mobile site__ (for those that don't know this is an opt in service [1] and won't effect anyone who has no opted in). We invite community members to join the beta and help us survey and fix the damage. Since the inline style scrubbing only applies to the beta - it's business as usual elsewhere. The desktop site is not effected in any way.

2) We **allow** any inline styles that are annotated. I know ResourceLoader uses a @noflip annotation to prevent flipping of css rules for right to left text. Using the same idea we introduce the @mobilesafe annotation. When at the beginning of an inline style this annotation signals to the MobileFrontend extension NOT to scrub the inline style. For example, in the following html only foo2 would be scrubbed <div id='foo1' style="/*@mobilesafe*/padding:10px;"></div> <div id='foo2' style="padding:10px;"></div> results in the html: <div id='foo1' style="/*@mobilesafe*/padding:10px;"></div> <div id='foo2'></div> This is **key** as it allows template admins to do one of two things - move the inline styles into MediaWiki:Common.css (which allows us to easily fix them for mobile much easier and without !important rules) or prefix inline styles with @mobilesafe after they have verified they are purely presentational (and work on mobile).

3) We give community members a fixed time -e.g. 2/3 months - after which we will make this the default. This allows plenty of time for us to work together to fix inline styles across the site.

4) Obviously we will have a wiki page with guidance notes where we can report pitfalls as we discover in inline styles on the mobile site with explanations of how to fix to make this transition as smooth as possible.

After this time anyone unfamiliar/not bothered with making content mobile safe can still add inline styles to the desktop site but they will not touch the mobile site. We will achieved a brilliant thing of making our content accessible to our growing [2] mobile audience

Thoughts? Is this workable? Jon

[1] http://blog.wikimedia.org/2011/10/27/wikimedia-mobile-opt-in-beta/ [2] https://blog.wikimedia.org/2012/05/03/mobile-milestone-two-billion-page-view...

On Wed, Apr 25, 2012 at 8:32 PM, Daniel Friesen lists@nadir-seen-fire.com wrote:

On Wed, 25 Apr 2012 04:56:32 -0700, Jon Robson jrobson@wikimedia.org wrote:

...

...

We already don't validate. There's no point to trying to conform to a validator when the spec/validator is wrong. And we already have cases like that.

I think we should try to validate though mostly for future proofing...

...

Anyways, technically you could already use scoped anyways. Just add the scoped attribute. Don't use css that applies outside the content area. And then it'll validate, it'll work in browsers, and when browsers actually implement scoped they'll start restricting the scope.

<snip> > > But after you've dealt with all the XSS issues; you've opened up the > ability > to completely destroy the UI from within WikiText. In ways even worse > than > the tricks attempting to simply cover the whole UI with a div. Those > tricks > being ones you could technically eliminate by using overflow+relative on > the > content area and disallowing position: fixed; (The only thing in the way > of > that right now is WP's stupid page icon hack). > I think if we restricted css to templates that only trusted admins can edit then these problems goes away somewhat no?

Sure. Except since admins can already edit Common.css you just completely destroyed the point of putting css in WikiText. And you've introduced unstable behavior we don't want where the protection state of an article affects the presentation of the page content. If you temp protect a template all of a sudden when the protection expires the content changes in style. Additionally we don't necessarily purge parser cache on unprotect or tie protection state into the parser options/output. So such a thing bridges on making the parser even less self-contained.

-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Jon Robson wrote:

Sorry for the lack of continued discussion on this thread. I've been thinking lots and lots about this over the last weeks and would like to suggest a course of action.

I think we are agreed that the majority of inline styles come from templates and it is the templates we need to fix up.

I missed this thread in April, but no, I don't think there's agreement that it's the templates that need to be fixed. Maybe a few them need adjustments, but inline styling is unfairly being portrayed as a demon in this thread. I'd estimate that inline styling is present on over 99% of pages on the English Wikipedia, so any solution that involves removing inline styling is simply insane and a non-starter.

While you can put some styling into global pages, sometimes you need one particular element to be a different color or a different font weight or whatever. This flexibility can't be tossed out because it's inconvenient. As Brion noted, there's often _data_ stored in this styling (for example, a row can be highlighted in yellow and surrounding page text might reference this highlighting).

1. We turn on inline style scrubbing in the beta of the __mobile

site__ (for those that don't know this is an opt in service [1] and won't effect anyone who has no opted in). We invite community members to join the beta and help us survey and fix the damage. Since the inline style scrubbing only applies to the beta - it's business as usual elsewhere. The desktop site is not effected in any way.

Have you found a page (any page) that doesn't use any inline styling? It sounds like you're suggesting breaking every page on the mobile site. It's trivial to strip all inline styling, but I can't imagine that will improve the mobile experience for anyone.

2. We **allow** any inline styles that are annotated. I know

ResourceLoader uses a @noflip annotation to prevent flipping of css rules for right to left text. Using the same idea we introduce the @mobilesafe annotation. When at the beginning of an inline style this annotation signals to the MobileFrontend extension NOT to scrub the inline style. For example, in the following html only foo2 would be scrubbed

<div id='foo1' style="/*@mobilesafe*/padding:10px;"></div> <div id='foo2' style="padding:10px;"></div> results in the html: <div id='foo1' style="/*@mobilesafe*/padding:10px;"></div> <div id='foo2'></div> This is **key** as it allows template admins to do one of two things - move the inline styles into MediaWiki:Common.css (which allows us to easily fix them for mobile much easier and without !important rules) or prefix inline styles with @mobilesafe after they have verified they are purely presentational (and work on mobile).

I understand the intention here, but this seems pretty nasty. While I generally favor being explicit over being implicit, this is one case where it'd be nice if the rendering "just works" without requiring human intervention for every page. If anything, you could do the opposite: have a "stripformobile" keyword that removes problematic styling in certain specific cases, but that needs further consideration.

I'm still having difficulty understanding your overall problem. "margin: -1px 21em 0 0;" is pretty stupid code, regardless of device. Specific problems like this are easy enough to address. Is there any reason for the proposed additional complexity? Stripping all inline styling is "cut off your arm because your nails need to be cut" thinking.

MZMcBride

What about this idea: We could introduce a new CSS class called 'nomobile' that functioned similarly to 'noprint' — any element set to this class would be hidden completely on mobile devices. If someone noticed a problem with a specific template on mobile devices, they could either fix the template or set it to 'nomobile'. This would make template creators aware of the problem and give them an incentive to fix their inline styles.

Ryan Kaldari

On 5/10/12 7:13 PM, Krinkle wrote:

On May 10, 2012, at 8:52 PM, MZMcBride wrote:

...

Jon Robson wrote:

...

Sorry for the lack of continued discussion on this thread. I've been thinking lots and lots about this over the last weeks and would like to suggest a course of action.

I think we are agreed that the majority of inline styles come from templates and it is the templates we need to fix up.

I missed this thread in April, but no, I don't think there's agreement that it's the templates that need to be fixed. Maybe a few them need adjustments, but inline styling is unfairly being portrayed as a demon in this thread. I'd estimate that inline styling is present on over 99% of pages on the English Wikipedia, so any solution that involves removing inline styling is simply insane and a non-starter.

While you can put some styling into global pages, sometimes you need one particular element to be a different color or a different font weight or whatever. This flexibility can't be tossed out because it's inconvenient. As Brion noted, there's often _data_ stored in this styling (for example, a row can be highlighted in yellow and surrounding page text might reference this highlighting).

I agree with MZMcBride. The problematic nature of some inline styles, or rather, the problematic nature of layouts that aren't compatible with mobile in general, is greatly exaggerated.

I'm not denying the problem. I merely believe that this problem, although it may be very visible and problematic for the user, can be handled with a simple more effective solution. A solution that is less likely to introduce a new set of problems in the process.

We shouldn't handle this much differently than other platform changes we've seen in the past. Think of new browser releases, monitor size changes, CSS/JavaScript support, browser bugs etc.

People learn about those things, and once they do we document them and take them into account from that point on. And whenever a problem of that kind is encountered or pointed out in old stuff that didn't comply, it is fixed.

I don't doubt that there are likely lots of templates, gadgets and user scripts in the wild that aren't as cross-browser compatible as MediaWiki core itself. Some templates may look completely broken -right now- for users with a certain window size on a computer with a certain operating system using a certain version of a certain browser. And when we come across that or when it is pointed out or when we can find them in batch using an algorithm, we (and/or/with the community) will fix them.

There may be exceptions, but overal it is an achievable goal to have 1-version fits all (for the parser content output), like we've been doing so far.

No rearranging, stripping or filtering of any kind, please. It is already annoying that MobileFrontend didn't load most of the front-end stack (such as site scripts that provide collapsing functionality[1]) which made some content look awkward or broken.

MZMcBride wrote:

...

Jon Robson wrote:

...

2. We **allow** any inline styles that are annotated. I know

ResourceLoader uses a @noflip annotation to prevent flipping of css rules for right to left text. Using the same idea we introduce the @mobilesafe annotation. When at the beginning of an inline style this annotation signals to the MobileFrontend extension NOT to scrub the inline style. For example, in the following html only foo2 would be scrubbed

<div id='foo1' style="/*@mobilesafe*/padding:10px;"></div> <div id='foo2' style="padding:10px;"></div> results in the html: [..]

[..] I understand the intention here, but this seems pretty nasty. While I generally favor being explicit over being implicit, this is one case where it'd be nice if the rendering "just works" without requiring human intervention for every page. If anything, you could do the opposite: have a "stripformobile" keyword that removes problematic styling in certain specific cases, but that needs further consideration.

The example that MZMcBride gave earlier, about highlighting something in text or in table rows, is a good one. Inline styles are used inside an article, or with a nested factory template that eventually wraps content in an inline element with inline styling. Stripping by default is not an option.

In a perfect world we would've had modules for this from the beginning and highlighting something would be as easy as clicking a button in an editor, which would use a css class underneath and add a dependency for the highlight-module to the page. That module would contain styling for that class. And a ResourceLoader module can include different sub-stylesheets in the module package based on the active skin (vector, monobook, mobile-frontend?). But that's not the reality (yet).

Also, when thinking about it further, I can't think of any well-written template (new or old) that should use "@mobilesafe" (or "@stripformobile" for that matter) for styling differences.

Some of you may remember that famous presentation (can't remember the name) about securing your application in one of the best ways, while actually being lazy and not primary caring about security.

An interesting logic I learned from that is: Addressing a problem, without being very specific to one particular downside of the cause. Because one would apply best practices for other reasons (practices that happen to naturally also enforce good security). You wouldn't have to care about security at all to consider using those practices.

Similarly, back to the mobile subject, those Portal layouts and templates can be improved in general, not just because they look bad or aren't user friendly on a mobile device. Some of those are probably also not very usable on a desktop browser when resizing the window very narrow or when widening it a lot on a high-resolution monitor. Which would either show a scrollbar instead of flowing the second "column" of boxes underneath, or (on the large screen) it would make the two columns very wide instead of letting the showing the boxes underneath next to the first two on the first row.

This example is for example about a table-code layout vs. row containers with floating elements.

-- Krinkle

[1] Note that at the time (maybe still today) those [expand]/[collapse] buttons from those Wikipedia templates are shown regardless of javascript (which is another problem). So they are broken on mobile without the site scripts. The absence of site scripts is a known issue, and from what I heard this wil be fixed once MobileFrontend uses the built-in load stack of MediaWiki (with ResourceLoader), instead of overruling it with a manually maintained stack.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On May 11, 2012, at 11:17 AM, Tei wrote:

On 11 May 2012 10:24, Ryan Kaldari rkaldari@wikimedia.org wrote:

...

What about this idea: We could introduce a new CSS class called 'nomobile' that functioned similarly to 'noprint' — any element set to this class would be hidden completely on mobile devices. If someone noticed a problem with a specific template on mobile devices, they could either fix the template or set it to 'nomobile'. This would make template creators aware of the problem and give them an incentive to fix their inline styles.

http://www.stuffandnonsense.co.uk/archives/images/specificitywars-05v2.jpg

I think theres a limitation to that, ".nomobile .darthvader .darthvader" will not work as expected (I think)

As far as CSS is concerned this will work just fine. Due to a logic error in the mobile site specifically it can fail sometimes. But CSS has no such bug or limitation, and in MediaWiki it will work just fine.

Not sure how that link is relevant..

-- Krinkle

On 2012-06-05 14:16, Jon Robson wrote:

I still think inline styles are going to continue causing problems on the mobile site as many people creating articles may only me thinking in terms of how a page will look in desktop rather than mobile.

It could help if the edit page had an option to "preview for mobile". Not everybody would have to use that, but those interested in helping out could do so.

On 05.06.2012, 16:16 Jon wrote:

I still think inline styles are going to continue causing problems on the mobile site as many people creating articles may only me thinking in terms of how a page will look in desktop rather than mobile. Although I personally would turn them off on the mobile website I seem to be in a minority.

I spoke to several people including Gabriel Wicke and Brion Vibber on this subject at the Berlin hackathon and I think possibly the best way we as a community can address this is to identify the problems on a case by case basis.

To do this I've created a page [1] the idea being that community members can report/identify situations where inline styles don't work on the mobile site, document them and provide a suggested resolution. These situations can then be linked to a list of effected pages that require cleaning up, for example [2]. These lists can be generated using Gabriel's dumpGrepper.js [3]. For the time being I've just run a grep on English Wikipedia but depending on whether this is successful I'll branch out to other languages

Hopefully this will result in some sort of reference page for how to write styles that work well on both mobile and desktop.

I think we should strive to leave HTML transformation behind - for non-WAP devices we could rely on CSS only. DOM parsing made a lot of sense at the time of the Ruby gateway which had to parse HTML for screen-scraping anyway. However, now by avoiding HTML parsing we could:

* Avoid performance reduction for mobile requests * Make out output more uniform * Stop relying on that unsalvageable piece of crap called libxml

For specific cases when there's a lot of desktop HTML that doesn't need to be shown to mobile users at all, we could tweak the parser to ouptut mobile-specific HTML, but this should be restricted to minimum.

On 08.06.2012, 23:25 Derk-Jan wrote:

...

I think we should strive to leave HTML transformation behind - for non-WAP devices we could rely on CSS only. DOM parsing made a lot of sense at the time of the Ruby gateway which had to parse HTML for screen-scraping anyway. However, now by avoiding HTML parsing we could:

• Avoid performance reduction for mobile requests
• Make out output more uniform
• Stop relying on that unsalvageable piece of crap called libxml

For specific cases when there's a lot of desktop HTML that doesn't need to be shown to mobile users at all, we could tweak the parser to ouptut mobile-specific HTML, but this should be restricted to minimum.

As much as I would love to have it that way, reality in mobile apps and web apps over the past 3 years have shown me that only works for Android and iOS. Any older feature phones are, in terms of HTML parsing capability, hardly better than the old WAP phones. HTML5 and XHTML 1.0 don't mix very well in the real world.

Well, we already serve either WML or HTML5, no middle ground :)

Bump... does anyone have any objections to this experiment? Jon

On Tue, Jun 19, 2012 at 5:28 PM, Jon Robson jdlrobson@gmail.com wrote:

So crowdsourcing fixes for inline styles doesn't seem to be the most effective method [1]. I've been quite swamped with other work just as I'm sure others have been. As a result various wiki pages are still rendering badly/unreadable. I understand that there are certain circumstances where it is useful to be able to have complete control over styling as a article writer, but I'd also argue that most article writers are not designers so what were are doing in allowing this is introducing a huge variable of complexity that allows anyone to introduce CSS that could potentially be non-performant (transitions), broken or as I am finding stuff that just doesn't work on mobile [2]. This scares me as someone who cares about providing a good experience to all our users on various devices.

I ask you again... //Are inline styles on the __mobile site__ really worth the trade off?//

More concretely can anyone give me a specific example of an inline style that is essential on mobile that we simply cannot scrub?

I would confidently bet that if we were to turn off inline styles on the mobile site we wouldn't miss it much, and I'd much rather deal with things we do miss on a case by case basis, as at least we'd have a clean readable mobile site as a starting point. I also think people are much more motivated to fix things that they previously had and no longer have in comparison to fixing things that are currently broken.

I'm sure all developers would agree that enhancements are always more fun then bugs.. :-)

Can I at least get some consensus to ***try*** scrubbing inline styles on the beta of the mobile site? Note this would have no effect whatsoever on the desktop site and if we are not happy with it we just scrap it. I'm sure if we try it we might find we like it....

[1] http://www.mediawiki.org/w/index.php?title=Making_MediaWiki_Mobile_Friendly/... [2] http://www.mediawiki.org/wiki/Making_MediaWiki_Mobile_Friendly

On Fri, Jun 8, 2012 at 2:07 PM, Max Semenik maxsem.wiki@gmail.com wrote:

...

On 08.06.2012, 23:25 Derk-Jan wrote:

...

...

I think we should strive to leave HTML transformation behind - for non-WAP devices we could rely on CSS only. DOM parsing made a lot of sense at the time of the Ruby gateway which had to parse HTML for screen-scraping anyway. However, now by avoiding HTML parsing we could:

• Avoid performance reduction for mobile requests
• Make out output more uniform
• Stop relying on that unsalvageable piece of crap called libxml

For specific cases when there's a lot of desktop HTML that doesn't need to be shown to mobile users at all, we could tweak the parser to ouptut mobile-specific HTML, but this should be restricted to minimum.

...

As much as I would love to have it that way, reality in mobile apps and web apps over the past 3 years have shown me that only works for Android and iOS. Any older feature phones are, in terms of HTML parsing capability, hardly better than the old WAP phones. HTML5 and XHTML 1.0 don't mix very well in the real world.

Well, we already serve either WML or HTML5,  no middle ground :)

-- Best regards,  Max Semenik ([[User:MaxSem]])

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

-- Jon Robson http://jonrobson.me.uk @rakugojon

On 27/06/12 20:39, Jon Robson wrote:

Bump... does anyone have any objections to this experiment? Jon

Seems my reply didn't go through the mailing list. Resending:

I guess you could add a ?stripinlinepagestyles=0 parameter. That would allow to test for pages sanity in that mode (or ?stripinlinepagestyles=1 to ensure it was that what broke the pages).

It's hard that someone gives you an example without providing a way to evaluate it.

On Wed, Jun 27, 2012 at 6:35 PM, Krinkle krinklemail@gmail.com wrote:

So, stripping inline styles:

• will not fix bad layouts made with tables (which are probably at least as

common as bad layouts made with inline styles).

• will break unrelated things, because inline styles are not directlty

related to layout, they're used for many things.

I think provided that there is the following documentation:

• which layout patterns are problematic (whether with inline styles,

tables or by other means),

• why/how they cause problems
• how to solve that (and how the solution is indeed better for everyone)

... then is is a matter of spreading links to that documentation and waiting for it to be incorporated on the 700+ wikis with the many many portal pages, and other structures that have bad layouts.

I'm generally in agreement with Krinkle on this. But I have to warn that just spreading documentation doesn't magically make things happen -- we probably have to put some actual human effort into finding and fixing broken layouts.

A one-button "report bad layout on this page" thingy might well be nice for that; as could an easy "preview this page for mobile" from the edit page. (Though to be fair, people can switch from desktop to mobile layout with one click -- worth trying out!)

-- brion

2012/6/28 Jon Robson jdlrobson@gmail.com:

# "things rely on those inline styles whether we like it or not." No... They rely on styles not //inline// styles. This is my main problem with the current setup! I believe the majority of things done in inline styles that are essential would be better done in MediaWiki:Common.css - if we have text that is red this would be better down with a class markedRed otherwise some text risks being red or and other text #BE3B3B despite meaning the same thing. Most layout problems on mobile can be fixed with media queries. You can't do these in inline styles.

This makes no sense. Are you suggesting we create CSS classes markedX for every one of the approx. 150 color names accepted by browsers, as well as for every possible capitalization of these names? Because that's what we should do to avoid having "markedRed" word but "markedPurple" not for no user-visible reason.

(And I didn't even start to mention how this makes even less sense semantically than inline styles. What if one text is marked with "markedRed" and other is marked the same way despite meaning *different* things?)

What would sort of make sense would be classes like "wrong", "no" or "decrease", which would all have the same red color, but would mean different things. But now we're heading for unnecessary obstacles to editors...

-- Matma Rex

...

What would sort of make sense would be classes like "wrong", "no" or "decrease", which would all have the same red color, but would mean different things. But now we're heading for unnecessary obstacles to editors...

Yes. Agreed. I just picked an arbitrary class name here. The only point I was trying to make is moving inline styles to a class gives us more consistency. If the color red means 'wrong' we should call the class wrong. I wasn't for one minute suggesting we should introduce classes for every specific color.. that would just be stupid :P

I like the idea of class names for different things, and I don't think that it would unduly burden the editor. As they are already using inline styles, I think that using classes shouldn't be an undue burden. It is no harder to say class="someClass" than it is to say style="color: #123456", in fact, I would argue it is easier.

Thank you, Derric Atzrott Computer Specialist Alizee Pathology

Assuming you remember all the class names, which ones will "work" and which will not (or, worst case, you have documentation handy).

I'd hope documentation would help with identifying class names and one could imagine extending the visual editor for the most common ones in future.

Why would certain ones work and certain ones not? With a stylesheet solution every class should work... (there would possibly just be different styling rules for those elements for mobile / print etc.. )

Replies inline:

On Jun 28, 2012, at 7:38 PM, Jon Robson wrote:

# "things rely on those inline styles whether we like it or not." No... They rely on styles not //inline// styles. This is my main problem with the current setup! I believe the majority of things done in inline styles that are essential would be better done in MediaWiki:Common.css - if we have text that is red this would be better down with a class markedRed otherwise some text risks being red or and other text #BE3B3B despite meaning the same thing. Most layout problems on mobile can be fixed with media queries. You can't do these in inline styles.

Hold on, we're in misunderstanding :). We agree.

So, they *do* rely on inline styles. But when I said "they rely" I meant: they currently use them to do something that should not be removed. You won't hear me say we "need" inline styles (there is not a single layout best done through inline styles). I'm saying they are in use - right now - and fulfilling valid needs to the point that they can break or make an article.

Obviously they should become css classes loaded through modules like MediaWiki:Common.css and what not. I will +1 any movement towards deprecating them entirely from wikitext in MediaWii core. But not for just for mobile and not without at least a year of migration time for live sites (possibly with an opt-in feature before that for users to preview articles without inline styles to help fixing them).

Indeed, media queries work best for classes as well. But even then, those media queries belong where the styles are defined (whether or not in a seperate "mobile" wiki css page), but *not* in MobileFrontend, so this should not be a concern here.

# I believe beta users of the mobile is a very small number of dedicated Wikipedians. The nostyle=true suggestion by MZMcBride would be a great idea but my only worry is with it that no one would use it as users would have to add the query string to every page. This is why I suggested the beta as the problem would be in front of people's faces on every page view and the problems would get surfaced better. FWIW I was thinking more of a javascript implementation - $("[style"]).removeAttr("style") - this way disabling javascript would get people back their styles in a worst case of scenario and it would not effect performance on the server.

From JavaScript it is a lot easier to implement, but does bring issues with interactive states (such as display: none; ) - which, although even those could be done as a css classes, are even more common.

I'm not sure what else to say really... I could understand backlash if I was suggesting turning off inline styles on the desktop site or even the mobile site - but all I'm suggesting here is targeting the beta of mobile.

I'm not doubting your judgement. If you believe it is useful to experiment with this in the beta. I'd say go ahead, deploy it today (its not like you need our permission or anything :-P). But as I mentioned earlier, I'm not sure what we would get out of such experiment, since we already seem to know what it will break and make.

Thanks for everyones contributions so far on this long thread! I really do appreciate this discussion and your patience with me :-).

Thanks for making the mobile site awesome!

-- Krinkle

On Thu, Jun 28, 2012 at 9:37 AM, Brion Vibber brion@pobox.com wrote:

...

On Wed, Jun 27, 2012 at 6:35 PM, Krinkle krinklemail@gmail.com wrote:

...

So, stripping inline styles:

• will not fix bad layouts made with tables (which are probably at least as

common as bad layouts made with inline styles).

• will break unrelated things, because inline styles are not directlty

related to layout, they're used for many things.

I think provided that there is the following documentation:

• which layout patterns are problematic (whether with inline styles,

tables or by other means),

• why/how they cause problems
• how to solve that (and how the solution is indeed better for everyone)

... then is is a matter of spreading links to that documentation and waiting for it to be incorporated on the 700+ wikis with the many many portal pages, and other structures that have bad layouts.

I'm generally in agreement with Krinkle on this. But I have to warn that just spreading documentation doesn't magically make things happen -- we probably have to put some actual human effort into finding and fixing broken layouts.

A one-button "report bad layout on this page" thingy might well be nice for that; as could an easy "preview this page for mobile" from the edit page. (Though to be fair, people can switch from desktop to mobile layout with one click -- worth trying out!)

-- brion

-- Jon Robson http://jonrobson.me.uk @rakugojon

Yes, please, because fixing things such as (put your sunglasses first) https://pt.wikipedia.org/?oldid=30926886&action=edit%C2%A7ion=3&prev... is a PITA and will take years! (there are tons of it!)

Wow! This is exactly why I think inline styles might be a bad thing :-) - this really draws attention of the user away from the content.

I've started a wiki page for this discussion - it seems like a better place to do this from now on since this thread has already been confused and gained a lot of length! I've given it the generic heading 'Deprecating Inline Styles' and when I get time will add a mobile specific section: http://www.mediawiki.org/wiki/Deprecating_Inline_Styles

Hey John Sorry it seems my e-mail wasn't worded well... it makes it seem like that specific example was the catalyst for creating that wiki page when in fact the wiki page was created to discuss the __whole of this thread__ (I'm not sure if you've been following it or not).

I would personally appreciate your input on it as I believe you've got a lot of experience in mobile development. Best wishes Jon

On Mon, Jul 2, 2012 at 10:20 AM, John Du Hart compwhizii@gmail.com wrote:

So you've found and instance of where a user has poor design skills and you immediate response to that is to start a discussion on killing inline styles? Give me a break. On Jul 2, 2012 10:43 AM, "Jon Robson" jdlrobson@gmail.com wrote:

...

...

Yes, please, because fixing things such as (put your sunglasses first)

https://pt.wikipedia.org/?oldid=30926886&action=edit%C2%A7ion=3&prev...

...

is a PITA and will take years! (there are tons of it!)

Wow! This is exactly why I think inline styles might be a bad thing :-) - this really draws attention of the user away from the content.

I've started a wiki page for this discussion - it seems like a better place to do this from now on since this thread has already been confused and gained a lot of length! I've given it the generic heading 'Deprecating Inline Styles' and when I get time will add a mobile specific section: http://www.mediawiki.org/wiki/Deprecating_Inline_Styles

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Jon Robson wrote:

More concretely can anyone give me a specific example of an inline style that is essential on mobile that we simply cannot scrub?

We've been over this repeatedly, haven't we? Sometimes there is _data_ in the styling. If you strip out the styling, you'll be throwing away this data. I'm not sure why you're still questioning this or how you've been unable to find specific examples of this. Search the English Wikipedia for phrases such as "marked in green" or "marked in red" or whatever.

Can I at least get some consensus to ***try*** scrubbing inline styles on the beta of the mobile site?

I don't think there's any consensus to implement inline style stripping. However, if you want to write the code and stick it behind a URL parameter (?nostyles=true, e.g.), it'd be interesting to see the results. Abstract the code and if striping inline styles really is everything you dreamed of, you can kill the URL parameter later (or flip the implicit default)? That'd be my approach here.

So crowdsourcing fixes for inline styles doesn't seem to be the most effective method [1]. [1]

http://www.mediawiki.org/w/index.php?title=Making_MediaWiki_Mobile_Friendly/... _of_portal_pages_with_problematic_two_column_layouts&action=history

I was going to suggest that you create reports like this before realizing that you already had. The issue you're having is that these reports are unadvertised and they're on the wrong wiki. I've run https://en.wikipedia.org/wiki/Wikipedia:Database_reports for a few years. You'd be shocked what kind of stupid shit people like to fix. If you get some automated/semi-automated reports up on the English Wikipedia (so that people can watchlist the pages), explain what the issues are and how to resolve them (link to MediaWiki.org documentation as necessary), advertise the reports, and then wait, you'll find more success. This is a much better approach than creating obscure subpages on mediawiki.org.

As Krinkle says, you need to be patient. The horribly broken pages that keep you awake at night will generally be fixed first in a crowdsourced world. The subtle breakage throughout the site will be fixed over time (or those shitty phones with their shitty browsers will eventually die out in the wild).

MZMcBride

On Thu, Jun 28, 2012 at 4:32 PM, Tei oscar.vives@gmail.com wrote:

You can always have a line on the bottom of a mobile page, with  "Do the page render correctly?". And somehow use it to "flag" pages that render incorrectly.  Wooot, perhaps this flagging may even save the user agent of the visitor using the link.

--

ℱin del ℳensaje.

You and what privacy policy/Access to nonpublic data policy are going to process that user agent?

On 28 June 2012 04:21, MZMcBride z@mzmcbride.com wrote:

Jon Robson wrote:

...

More concretely can anyone give me a specific example of an inline style that is essential on mobile that we simply cannot scrub?

We've been over this repeatedly, haven't we? Sometimes there is _data_ in the styling. If you strip out the styling, you'll be throwing away this data. I'm not sure why you're still questioning this or how you've been unable to find specific examples of this. Search the English Wikipedia for phrases such as "marked in green" or "marked in red" or whatever.

I just want to point out that colour alone *should not* be used to convey data, for accessibility reasons. https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Accessibility#Color (Yes I realise that's an en.wikipedia guideline, but similar principles ought to apply across all projects)

Pete / the wub

It would be good if possible to get a more accurate feel for what percentage of articles use inline styles. e.g. articles that contain style= vs articles that don't This would help us get a better idea of what we are dealing with.

The example given of highlighting - I understand the need for something like this - but this sounds like it would be better off as a global style in MediaWiki:Common.css so highlighting is consistent across all wiki articles. If one template is highlighting text in yellow and another in orange and they are trying to emphasise the same thing this is not so good in my opinion!

My main issue with inline styles is the mixing of css and html. I still think it would be much more manageable if templates were able to manage their own stylesheets instead and use classes for styling purposes but as I understand this could be a tricky manoeuvre.

I don't think a nomobile class would help here - if something is broken now on the mobile site why would someone add a nomobile class rather than fixing the inline style? Also rendering the content badly is probably better than not rendering it at all.

I think our main goal should be an agreed way to cleanup these inline styles effectively. The current procedure for cleaning these up is not working in my opinion as bug 36076 [1] was raised in the middle of April and a duplicate bug 36750 [2] was raised almost half a month later despite some discussion around the subject.

The example of the track listings is caused by an inline style margin:-1px 21em 0 0; - there is no reason this should not be used on the desktop site - but obviously this is not fit for purpose on the mobile site. If this was styled via a stylesheet (either MediaWiki:Common.css or other) these rules can be optimised for mobile (the mobile site body tag carries a class 'mobile' and there are of course media queries)

I still think the turning off inline styles on the beta has merit as it provides us an effective method of working out which styles are essential to both mobile and desktop and should be in stylesheets rather than existing as inline styles. If we are not keen on the @mobilesafe annotation there is no reason we have to go down that route.

So another course of action might be: 1) scrub inline styles in the beta of the mobile site 2) assess damage and shift all important and generic inline styles to stylesheets - this will take time but is a very worthwhile community exercise (in my opinion this would be anything involving floats, margins, padding and fixed widths) 3) add mobile specific styles for these to stylesheets 4) Turn off inline style scrubbing in beta 5) Introduce guidelines for when things should be inline styles and when not to try to prevent us getting to this point again in the future 6 (long term) Deprecate the need for inline styles by allowing css declarations within wikitext.

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=36076 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=36740

On Fri, May 11, 2012 at 2:17 PM, Max Semenik maxsem.wiki@gmail.com wrote:

On 11.05.2012, 12:24 Ryan wrote:

...

What about this idea: We could introduce a new CSS class called 'nomobile' that functioned similarly to 'noprint' — any element set to this class would be hidden completely on mobile devices. If someone noticed a problem with a specific template on mobile devices, they could either fix the template or set it to 'nomobile'. This would make template creators aware of the problem and give them an incentive to fix their inline styles.

Such functionality already exists, even with the same class name ;-8 However, there's a problem with this code[1] that prevents it from working in all situations.

---

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=36742

-- Best regards,  Max Semenik ([[User:MaxSem]])

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Am 11.05.2012 10:24, schrieb Ryan Kaldari:

What about this idea: We could introduce a new CSS class called 'nomobile' that functioned similarly to 'noprint' —

as we are talking about this - yes, I know [1]) -

in a previous posting on #mediawiki_

I already asked to introduce a new class _ * .noscreen*

to disable elements when rendered on */screen /*media, similar to .noprint

.noscreen { display: none; }

In older MW versions I could easily add that. In the current MW core, I did not find a way to get it working. Now knowing [1], it might be a consequence from that.

Perhaps anyone can help here, too ?

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=36742 Elements with blacklisted class get removed only if it's their only class

Daniel Friesen wrote:

Saying that inline styles are present on over 99% pages on en.wp is a logical fallacy. 99% of articles may have inline styles in their output but the only pages that are an actual issue are ones where the inline styles are in the content themselves not in embedded templates. If we have 1000 pages with 1 template and inline styles inside the template, then we only have to fix the one template. NOT the 1000 pages.

Don't underestimate template changes or bots.

I don't underestimate. Yes, you can make a mess and then clean it up. It doesn't make the process any more enjoyable. And the context was disabling (all) inline styling. My point was that currently that would break nearly every page in some way.

...

While you can put some styling into global pages, sometimes you need one particular element to be a different color or a different font weight or whatever. This flexibility can't be tossed out because it's inconvenient. As Brion noted, there's often _data_ stored in this styling (for example, a row can be highlighted in yellow and surrounding page text might reference this highlighting).

...

1. We turn on inline style scrubbing in the beta of the __mobile

site__ (for those that don't know this is an opt in service [1] and won't effect anyone who has no opted in). We invite community members to join the beta and help us survey and fix the damage. Since the inline style scrubbing only applies to the beta - it's business as usual elsewhere. The desktop site is not effected in any way.

Have you found a page (any page) that doesn't use any inline styling? It sounds like you're suggesting breaking every page on the mobile site. It's trivial to strip all inline styling, but I can't imagine that will improve the mobile experience for anyone.

Selection of pages from Special:Random:

• https://en.wikipedia.org/wiki/Vic_Belsham - No explicit inline styles

Maybe we're not talking about the same thing, then? I see plenty of inline styling throughout the page source of this page. E.g., <table class="infobox vcard" style="width: 25em; font-size: 88%; line-height: 1.5em">

As far as I understand it, this is a conversation about stripping all inline styling, not just styling from the articles themselves. Which is what I think these examples are?

Back on point, I think nomobile is a good idea. People have been using multiple classes as a hack to force content to be rendered, even: https://bugzilla.wikimedia.org/show_bug.cgi?id=29157#c2.

MZMcBride

In terms of detection we could suggest when they might be a problem however if we were to use an algorithm it is likely to highlight mobile safe pages as having a problem. For instance if a page had an inline style width:300px; this could cause problems on a mobile device with a window width of less than 300px but on other devices it would appear fine.

If we are to identify problematic pages I'd prefer some kind of crowd-sourced approach where a reader can report a page as having problems. If would then be good to see which of those pages share templates. I think Platonides is right in that most inline styles come from templates so an approach as suggested by Trevor does sound quite sensible and realistic but as Trevor says it will take time.

FWIW problematic CSS that I have identified so far include: * Margins and paddings that are not %s e.g. -1px 21em 0 0; * Any fixed widths can cause problems e.g. width:300px; * Any use of top, left, right, bottom which uses a pixel value e.g. left: 300px; * Any use of float or clear - the mobile site does strip certain content (at the moment) that is known to cause problems. These items might be clearing these floats and without them could lead to problems. * -webkit-column-count greater than 1 can cause issues (tends to be used mostly in references and notes sections)

On a side note there is also problematic HTML that would benefit from being able to be styled via css rather than inline styles. The one I can think of off of the top of my head is image maps as these rely on fixed widths.

Although I think a stylesheet per wiki page would be great I can see problems in this in terms of ResourceLoader working out where to gather styles from. I'm a bit worried about allowing style tags in the template namespace as I'd like us one day to W3C validate :-) and personally I'd worry that mixing wikitext and css could make templates even more hard to decipher. I think this would benefit from a clear separation... Could templates have a CSS page (similar to how each page has a talk page)? This 'CSS page' could then be served either as a style tag in the head of the wiki page or even better pushed into ResourceLoader.

I think the solution we seem to be arriving at (please correct me if I'm wrong) is... * 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

Note that already the mobile site has a mobile class on the body tag [1] to allow users to specifically target the mobile site (note this possibly should be on the html tag)

[1] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend....

On Fri, Apr 20, 2012 at 9:44 PM, Platonides Platonides@gmail.com wrote:

Yesterday, someone asked #wikipedia where was the separation between style and content done on wikipedia. Users don't suddenly start to write CSS rules in the pages themselves. Most inline styles come from templates.

They don't write for a table:  border="2" cellpadding="4" cellspacing="0"  style="margin: 0.5em 0.5em 0.5em 1em; padding: 0.5em; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; font-size: 95%;  but do {{tabla bonita}}

Similarly, the infoboxes CSS don't come from the article content, but from a template two or three layers down.

Fixing 80-90% of the inline styles should be quite simple, as it'll come from a few templates. The problem is to detect *when* that style gives problems on mobile.

I'm not sure what we are trying to mean with it, "it doesn't look right" isn't simple for an algorithm to detect ;) If we need to manually view the page, we could hardly detect it.

OTOH if we are looking for absolute values in that inline, it's  simple to do.

So what constructs are problematic for mobile? How to detect them?

Once we have such measures, it shouldn't be hard to go fixing it. Moving css rules from inline styles to site CSS can be a step for fixing the problems (and also recommendable for other reasons), but is not the solution.

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Fri, Apr 20, 2012 at 3:30 PM, Jon Robson jdlrobson@gmail.com wrote:

...

...

** one could imagine pages/templates being able to maintain their own stylesheets for desktop and mobile to allow customisations

^^^ this would be very useful!

Is that something that has been discussed before and is feasible? It would certainly be useful for mobile as we could apply page specific hacks where needed to fix bugs on the mobile site rather than putting generic rules elsewhere.

There is https://bugzilla.wikimedia.org/show_bug.cgi?id=15075 (open since 2008), requesting a way to define CSS and JS specific to certain groups of pages (specifically the books on Wikibooks projects). If there was a way to define CSS for pages in a given category, wouldn't this solve both use cases?

Best regards, Helder