On Jun 27, 2012, at 8:39 PM, Jon Robson wrote: > Bump... does anyone have any objections to this experiment?
> On Tue, Jun 19, 2012 at 5:28 PM, Jon Robson <email@example.com> wrote:
>> So crowdsourcing fixes for inline styles doesn't seem to be the most
>> effective method . I've been quite swamped with other work just as
>> I'm sure others have been. As a result various wiki pages are still
>> rendering badly/unreadable. I understand that there are certain
>> circumstances where it is useful to be able to have complete control
>> over styling as a article writer, but I'd also argue that most article
>> writers are not designers so what were are doing in allowing this is
>> introducing a huge variable of complexity that allows anyone to
>> introduce CSS that could potentially be non-performant (transitions),
>> broken or as I am finding stuff that just doesn't work on mobile .
>> This scares me as someone who cares about providing a good experience
>> to all our users on various devices.
>> I ask you again... //Are inline styles on the __mobile site__ really
>> worth the trade off?//
I'm not sure how you conclude that asking the community to fix the issues
didn't work. These things take time, that's how it is. There is a ton of
content, and the community has a lot to do and many different priorities (which
I guess is the responsibility of the community, not the foundation or the
And no matter which path is taken, it is going to take time for the "bad" to
get "good" (either fixing bad layouts from the current perspective, or
stripping them out and ..then somehow fix everything that turned bad).
I think it makes sense to keep the inline styles untouched - as a status quo
(sorta). I've seen many good arguments go by in this thread (and other threads)
about how things rely on those inline styles whether we like it or not. I
believe we've seen enough examples that simply need to have these to the point
where I think it would be irrespondisble to just strip them (sure there is
better methods than inline styles to give those visual clues, but we already
know those methods are they are getting more common, it just takes time). I
doubt an experiment will teach us anything. We've got a pretty good idea of
what will break and what will get better by stripping them, right?
Also, here's something: inline styles in general are not the problem. Inline
styles are just a general purpose application that can be used for good and bad
(yes, there are better alternatives for the good applications of inline styles,
but that doesn't make them bad).
The real problem is outdated (or "bad") layout designs that don't adapt to
different screen resolutions, device orientation and/or window size. That
problem surfaces in various different ways. One of which is (certain) inline
1) Some layouts are done with inline styles, but not all inline styles are for
layout (on the contrary).
2) Some layouts are done with tables, not all tables are for layout.
3) Some layouts are done with from stylesheets in MediaWiki:Common.cs or
4) Other methods to create layouts.
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.
Wikitech-l mailing list