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