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
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
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) which made some content
look awkward or broken.
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
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
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
 Note that at the time (maybe still today) those [expand]/[collapse] buttons
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.