rkaldari at wikimedia
May 11, 2012, 1:24 AM
Post #18 of 59
What about this idea: We could introduce a new CSS class called
Re: Inline styles trouble on the mobile site
[In reply to]
'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.
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
> 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.
> 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
>  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.
> Wikitech-l mailing list
> Wikitech-l [at] lists
Wikitech-l mailing list
Wikitech-l [at] lists