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

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

^^^ this would be very useful!

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.

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.

On Apr 20, 2012 11:30 AM, "Jon Robson" &lt;jdlrobson(a)gmail.com&gt; wrote: that's Sorry meant <style> there! -- brion _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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(a)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(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

like I think we should try to validate though mostly for future proofing... And <snip> ability than tricks the of 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

On Wed, 25 Apr 2012 04:56:32 -0700, Jon Robson &lt;jrobson(a)wikimedia.org&gt; wrote: 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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.

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

On May 10, 2012, at 8:52 PM, MZMcBride wrote: 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: 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 11 May 2012 10:24, Ryan Kaldari &lt;rkaldari(a)wikimedia.org&gt; wrote: 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)

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.

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.

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.

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 &lt;maxsem.wiki(a)gmail.com&gt; wrote: -- Jon Robson http://jonrobson.me.uk @rakugojon

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

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.

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.

# "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.

> 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

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

# "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.

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

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.

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

On Thu, Jun 28, 2012 at 9:37 AM, Brion Vibber &lt;brion(a)pobox.com&gt; wrote: -- 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&section=3&… is a PITA and will take years! (there are tons of it!)

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" &lt;jdlrobson(a)gmail.com&gt; wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

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

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.

Jon Robson wrote: 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.

On 11.05.2012, 12:24 Ryan wrote: 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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.

Selection of pages from Special:Random: - https://en.wikipedia.org/wiki/Vic_Belsham - No explicit inline styles

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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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.