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 <br...@pobox.com> wrote:
>> On Wed, Jun 27, 2012 at 6:35 PM, Krinkle <krinklem...@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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
