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
