Mailing List Archive

1 2 3  View All
Re: Inline styles trouble on the mobile site [ In reply to ]
On Sat, May 12, 2012 at 10:26 AM, MZMcBride <z@mzmcbride.com> wrote:
> Maybe we're not talking about the same thing, then? I see plenty of inline
> styling throughout the page source of this page. E.g., <table class="infobox
> vcard" style="width: 25em; font-size: 88%; line-height: 1.5em">

I believe you are talking about the rendered HTML source of the page,
Where as Daniel is talking about the custom styling in the wikitext
for the aforementioned pages.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On May 11, 2012, at 11:17 AM, Tei wrote:

> On 11 May 2012 10:24, Ryan Kaldari <rkaldari@wikimedia.org> wrote:
>> What about this idea: We could introduce a new CSS class called '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.
>
>
> http://www.stuffandnonsense.co.uk/archives/images/specificitywars-05v2.jpg
>
> I think theres a limitation to that, ".nomobile .darthvader
> .darthvader" will not work as expected (I think)
>

As far as CSS is concerned this will work just fine. Due to a logic error in the mobile site specifically it can fail sometimes. But CSS has no such bug or limitation, and in MediaWiki it will work just fine.

Not sure how that link is relevant..

-- Krinkle


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
I still think inline styles are going to continue causing problems on
the mobile site as many people creating articles may only me thinking
in terms of how a page will look in desktop rather than mobile.
Although I personally would turn them off on the mobile website I seem
to be in a minority.

I spoke to several people including Gabriel Wicke and Brion Vibber on
this subject at the Berlin hackathon and I think possibly the best way
we as a community can address this is to identify the problems on a
case by case basis.

To do this I've created a page [1] the idea being that community
members can report/identify situations where inline styles don't work
on the mobile site, document them and provide a suggested resolution.
These situations can then be linked to a list of effected pages that
require cleaning up, for example [2]. These lists can be generated
using Gabriel's dumpGrepper.js [3]. For the time being I've just run a
grep on English Wikipedia but depending on whether this is successful
I'll branch out to other languages

Hopefully this will result in some sort of reference page for how to
write styles that work well on both mobile and desktop.

Please let me know if you do/don't think this is an effective way of
solving the problem, watch the page and most importantly help
contribute in the cleanup process!

[1] http://www.mediawiki.org/wiki/Making_MediaWiki_Mobile_Friendly
[2] http://www.mediawiki.org/wiki/List_of_Problematic_portal_pages_with_two_column_layouts
[3] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/VisualEditor.git;a=blob;f=tests/parser/dumpGrepper.js;h=6fa9feb5adfb8c9d7384a69dcd5b67791425add3;hb=master


On Mon, May 14, 2012 at 3:57 AM, Krinkle <krinklemail@gmail.com> wrote:
> On May 11, 2012, at 11:17 AM, Tei wrote:
>
>> On 11 May 2012 10:24, Ryan Kaldari <rkaldari@wikimedia.org> wrote:
>>> What about this idea: We could introduce a new CSS class called '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.
>>
>>
>> http://www.stuffandnonsense.co.uk/archives/images/specificitywars-05v2.jpg
>>
>> I think theres a limitation to that,   ".nomobile  .darthvader
>> .darthvader"   will not work as expected (I think)
>>
>
> As far as CSS is concerned this will work just fine. Due to a logic error in the mobile site specifically it can fail sometimes. But CSS has no such bug or limitation, and in MediaWiki it will work just fine.
>
> Not sure how that link is relevant..
>
> -- Krinkle
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jon Robson
http://jonrobson.me.uk
@rakugojon

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On 2012-06-05 14:16, Jon Robson wrote:
> I still think inline styles are going to continue causing problems on
> the mobile site as many people creating articles may only me thinking
> in terms of how a page will look in desktop rather than mobile.

It could help if the edit page had an option to "preview for mobile".
Not everybody would have to use that, but those interested in
helping out could do so.


--
Lars Aronsson (lars@aronsson.se)
Aronsson Datateknik - http://aronsson.se



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On 05/06/12 17:37, Lars Aronsson wrote:
> On 2012-06-05 14:16, Jon Robson wrote:
>> I still think inline styles are going to continue causing problems on
>> the mobile site as many people creating articles may only me thinking
>> in terms of how a page will look in desktop rather than mobile.
>
> It could help if the edit page had an option to "preview for mobile".
> Not everybody would have to use that, but those interested in
> helping out could do so.

Easy enough to make as a gadget.



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On 05.06.2012, 16:16 Jon wrote:

> I still think inline styles are going to continue causing problems on
> the mobile site as many people creating articles may only me thinking
> in terms of how a page will look in desktop rather than mobile.
> Although I personally would turn them off on the mobile website I seem
> to be in a minority.

> I spoke to several people including Gabriel Wicke and Brion Vibber on
> this subject at the Berlin hackathon and I think possibly the best way
> we as a community can address this is to identify the problems on a
> case by case basis.

> To do this I've created a page [1] the idea being that community
> members can report/identify situations where inline styles don't work
> on the mobile site, document them and provide a suggested resolution.
> These situations can then be linked to a list of effected pages that
> require cleaning up, for example [2]. These lists can be generated
> using Gabriel's dumpGrepper.js [3]. For the time being I've just run a
> grep on English Wikipedia but depending on whether this is successful
> I'll branch out to other languages

> Hopefully this will result in some sort of reference page for how to
> write styles that work well on both mobile and desktop.

I think we should strive to leave HTML transformation behind - for
non-WAP devices we could rely on CSS only. DOM parsing made a lot of
sense at the time of the Ruby gateway which had to parse HTML for
screen-scraping anyway. However, now by avoiding HTML parsing we
could:

* Avoid performance reduction for mobile requests
* Make out output more uniform
* Stop relying on that unsalvageable piece of crap called libxml

For specific cases when there's a lot of desktop HTML that doesn't
need to be shown to mobile users at all, we could tweak the parser to
ouptut mobile-specific HTML, but this should be restricted to minimum.

--
Best regards,
Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On Fri, Jun 8, 2012 at 5:12 PM, Max Semenik <maxsem.wiki@gmail.com> wrote:
> On 05.06.2012, 16:16 Jon wrote:
>
>> I still think inline styles are going to continue causing problems on
>> the mobile site as many people creating articles may only me thinking
>> in terms of how a page will look in desktop rather than mobile.
>> Although I personally would turn them off on the mobile website I seem
>> to be in a minority.
>
>> I spoke to several people including Gabriel Wicke and Brion Vibber on
>> this subject at the Berlin hackathon and I think possibly the best way
>> we as a community can address this is to identify the problems on a
>> case by case basis.
>
>> To do this I've created a page [1] the idea being that community
>> members can report/identify situations where inline styles don't work
>> on the mobile site, document them and provide a suggested resolution.
>> These situations can then be linked to a list of effected pages that
>> require cleaning up, for example [2]. These lists can be generated
>> using Gabriel's dumpGrepper.js [3]. For the time being I've just run a
>> grep on English Wikipedia but depending on whether this is successful
>> I'll branch out to other languages
>
>> Hopefully this will result in some sort of reference page for how to
>> write styles that work well on both mobile and desktop.
>
> I think we should strive to leave HTML transformation behind - for
> non-WAP devices we could rely on CSS only. DOM parsing made a lot of
> sense at the time of the Ruby gateway which had to parse HTML for
> screen-scraping anyway. However, now by avoiding HTML parsing we
> could:
>
> * Avoid performance reduction for mobile requests
> * Make out output more uniform
> * Stop relying on that unsalvageable piece of crap called libxml
>
> For specific cases when there's a lot of desktop HTML that doesn't
> need to be shown to mobile users at all, we could tweak the parser to
> ouptut mobile-specific HTML, but this should be restricted to minimum.

As much as I would love to have it that way, reality in mobile apps
and web apps over the past 3 years have shown me that only works for
Android and iOS. Any older feature phones are, in terms of HTML
parsing capability, hardly better than the old WAP phones. HTML5 and
XHTML 1.0 don't mix very well in the real world.

DJ

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On 08.06.2012, 23:25 Derk-Jan wrote:

>> I think we should strive to leave HTML transformation behind - for
>> non-WAP devices we could rely on CSS only. DOM parsing made a lot of
>> sense at the time of the Ruby gateway which had to parse HTML for
>> screen-scraping anyway. However, now by avoiding HTML parsing we
>> could:
>>
>> * Avoid performance reduction for mobile requests
>> * Make out output more uniform
>> * Stop relying on that unsalvageable piece of crap called libxml
>>
>> For specific cases when there's a lot of desktop HTML that doesn't
>> need to be shown to mobile users at all, we could tweak the parser to
>> ouptut mobile-specific HTML, but this should be restricted to minimum.

> As much as I would love to have it that way, reality in mobile apps
> and web apps over the past 3 years have shown me that only works for
> Android and iOS. Any older feature phones are, in terms of HTML
> parsing capability, hardly better than the old WAP phones. HTML5 and
> XHTML 1.0 don't mix very well in the real world.

Well, we already serve either WML or HTML5, no middle ground :)

--
Best regards,
Max Semenik ([[User:MaxSem]])


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
So crowdsourcing fixes for inline styles doesn't seem to be the most
effective method [1]. 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 [2].
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?//

More concretely can anyone give me a specific example of an inline
style that is essential on mobile that we simply cannot scrub?

I would confidently bet that if we were to turn off inline styles on
the mobile site we wouldn't miss it much, and I'd much rather deal
with things we do miss on a case by case basis, as at least we'd have
a clean readable mobile site as a starting point. I also think people
are much more motivated to fix things that they previously had and no
longer have in comparison to fixing things that are currently broken.

I'm sure all developers would agree that enhancements are always more
fun then bugs.. :-)

Can I at least get some consensus to ***try*** scrubbing inline styles
on the beta of the mobile site? Note this would have no effect
whatsoever on the desktop site and if we are not happy with it we just
scrap it. I'm sure if we try it we might find we like it....

[1] http://www.mediawiki.org/w/index.php?title=Making_MediaWiki_Mobile_Friendly/List_of_portal_pages_with_problematic_two_column_layouts&action=history
[2] http://www.mediawiki.org/wiki/Making_MediaWiki_Mobile_Friendly

On Fri, Jun 8, 2012 at 2:07 PM, Max Semenik <maxsem.wiki@gmail.com> wrote:
> On 08.06.2012, 23:25 Derk-Jan wrote:
>
>>> I think we should strive to leave HTML transformation behind - for
>>> non-WAP devices we could rely on CSS only. DOM parsing made a lot of
>>> sense at the time of the Ruby gateway which had to parse HTML for
>>> screen-scraping anyway. However, now by avoiding HTML parsing we
>>> could:
>>>
>>> * Avoid performance reduction for mobile requests
>>> * Make out output more uniform
>>> * Stop relying on that unsalvageable piece of crap called libxml
>>>
>>> For specific cases when there's a lot of desktop HTML that doesn't
>>> need to be shown to mobile users at all, we could tweak the parser to
>>> ouptut mobile-specific HTML, but this should be restricted to minimum.
>
>> As much as I would love to have it that way, reality in mobile apps
>> and web apps over the past 3 years have shown me that only works for
>> Android and iOS. Any older feature phones are, in terms of HTML
>> parsing capability, hardly better than the old WAP phones. HTML5 and
>> XHTML 1.0 don't mix very well in the real world.
>
> Well, we already serve either WML or HTML5,  no middle ground :)
>
> --
> Best regards,
>  Max Semenik ([[User:MaxSem]])
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jon Robson
http://jonrobson.me.uk
@rakugojon

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
Bump... does anyone have any objections to this experiment?
Jon

On Tue, Jun 19, 2012 at 5:28 PM, Jon Robson <jdlrobson@gmail.com> wrote:
> So crowdsourcing fixes for inline styles doesn't seem to be the most
> effective method [1]. 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 [2].
> 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?//
>
> More concretely can anyone give me a specific example of an inline
> style that is essential on mobile that we simply cannot scrub?
>
> I would confidently bet that if we were to turn off inline styles on
> the mobile site we wouldn't miss it much, and I'd much rather deal
> with things we do miss on a case by case basis, as at least we'd have
> a clean readable mobile site as a starting point. I also think people
> are much more motivated to fix things that they previously had and no
> longer have in comparison to fixing things that are currently broken.
>
> I'm sure all developers would agree that enhancements are always more
> fun then bugs.. :-)
>
> Can I at least get some consensus to ***try*** scrubbing inline styles
> on the beta of the mobile site? Note this would have no effect
> whatsoever on the desktop site and if we are not happy with it we just
> scrap it. I'm sure if we try it we might find we like it....
>
> [1] http://www.mediawiki.org/w/index.php?title=Making_MediaWiki_Mobile_Friendly/List_of_portal_pages_with_problematic_two_column_layouts&action=history
> [2] http://www.mediawiki.org/wiki/Making_MediaWiki_Mobile_Friendly
>
> On Fri, Jun 8, 2012 at 2:07 PM, Max Semenik <maxsem.wiki@gmail.com> wrote:
>> On 08.06.2012, 23:25 Derk-Jan wrote:
>>
>>>> I think we should strive to leave HTML transformation behind - for
>>>> non-WAP devices we could rely on CSS only. DOM parsing made a lot of
>>>> sense at the time of the Ruby gateway which had to parse HTML for
>>>> screen-scraping anyway. However, now by avoiding HTML parsing we
>>>> could:
>>>>
>>>> * Avoid performance reduction for mobile requests
>>>> * Make out output more uniform
>>>> * Stop relying on that unsalvageable piece of crap called libxml
>>>>
>>>> For specific cases when there's a lot of desktop HTML that doesn't
>>>> need to be shown to mobile users at all, we could tweak the parser to
>>>> ouptut mobile-specific HTML, but this should be restricted to minimum.
>>
>>> As much as I would love to have it that way, reality in mobile apps
>>> and web apps over the past 3 years have shown me that only works for
>>> Android and iOS. Any older feature phones are, in terms of HTML
>>> parsing capability, hardly better than the old WAP phones. HTML5 and
>>> XHTML 1.0 don't mix very well in the real world.
>>
>> Well, we already serve either WML or HTML5,  no middle ground :)
>>
>> --
>> Best regards,
>>  Max Semenik ([[User:MaxSem]])
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> Jon Robson
> http://jonrobson.me.uk
> @rakugojon



--
Jon Robson
http://jonrobson.me.uk
@rakugojon

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On 27/06/12 20:39, Jon Robson wrote:
> Bump... does anyone have any objections to this experiment?
> Jon

Seems my reply didn't go through the mailing list. Resending:
> I guess you could add a ?stripinlinepagestyles=0 parameter. That would
> allow to test for pages sanity in that mode (or ?stripinlinepagestyles=1
> to ensure it was that what broke the pages).
>
> It's hard that someone gives you an example without providing a way to
> evaluate it.


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On 27/06/12 20:39, Jon Robson wrote:
> Bump... does anyone have any objections to this experiment?
> Jon

Seems my reply didn't go through the mailing list. Resending:
> I guess you could add a ?stripinlinepagestyles=0 parameter. That would
> allow to test for pages sanity in that mode (or ?stripinlinepagestyles=1
> to ensure it was that what broke the pages).
>
> It's hard that someone gives you an example without providing a way to
> evaluate it.


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On Fri, Apr 20, 2012 at 3:30 PM, Jon Robson <jdlrobson@gmail.com> wrote:
>>> ** one could imagine pages/templates being able to maintain their own
>>> stylesheets for desktop and mobile to allow customisations
>>>
>>
>> ^^^ this would be very useful!
>
> Is that something that has been discussed before and is feasible? It
> would certainly be useful for mobile as we could apply page specific
> hacks where needed to fix bugs on the mobile site rather than putting
> generic rules elsewhere.

There is
https://bugzilla.wikimedia.org/show_bug.cgi?id=15075
(open since 2008), requesting a way to define CSS and JS specific to
certain groups of pages (specifically the books on Wikibooks
projects). If there was a way to define CSS for pages in a given
category, wouldn't this solve both use cases?

Best regards,
Helder

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On Mon, Apr 23, 2012 at 7:51 PM, Jon Robson <jrobson@wikimedia.org> wrote:
> (...) I think Platonides is right in that most inline styles come
> from templates... (...)

There are also things like the super-colored tables found in articles
like these:
https://pt.wikipedia.org/wiki/Category:Escolas_de_samba_de_São_Paulo?uselang=en
Has anyone tested that kind of page on Mobile to see if they also
cause problems?
(BTW: is there some tool which wikipedians could use to see the site
as if they were using mobile?)

Best regards,
Helder

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On Jun 27, 2012, at 8:39 PM, Jon Robson wrote:

> Bump... does anyone have any objections to this experiment?
> Jon
>
> On Tue, Jun 19, 2012 at 5:28 PM, Jon Robson <jdlrobson@gmail.com> wrote:
>> So crowdsourcing fixes for inline styles doesn't seem to be the most
>> effective method [1]. 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 [2].
>> 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
developers!).

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
styles.

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
MediaWiki:Skinname.css, or even depend on some JavaScript.
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.

-- Krinkle


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
Jon Robson wrote:
> More concretely can anyone give me a specific example of an inline
> style that is essential on mobile that we simply cannot scrub?

We've been over this repeatedly, haven't we? Sometimes there is _data_ in
the styling. If you strip out the styling, you'll be throwing away this
data. I'm not sure why you're still questioning this or how you've been
unable to find specific examples of this. Search the English Wikipedia for
phrases such as "marked in green" or "marked in red" or whatever.

> Can I at least get some consensus to ***try*** scrubbing inline styles
> on the beta of the mobile site?

I don't think there's any consensus to implement inline style stripping.
However, if you want to write the code and stick it behind a URL parameter
(?nostyles=true, e.g.), it'd be interesting to see the results. Abstract the
code and if striping inline styles really is everything you dreamed of, you
can kill the URL parameter later (or flip the implicit default)? That'd be
my approach here.

> So crowdsourcing fixes for inline styles doesn't seem to be the most
> effective method [1].
> [1]
http://www.mediawiki.org/w/index.php?title=Making_MediaWiki_Mobile_Friendly/List
_of_portal_pages_with_problematic_two_column_layouts&action=history

I was going to suggest that you create reports like this before realizing
that you already had. The issue you're having is that these reports are
unadvertised and they're on the wrong wiki. I've run
<https://en.wikipedia.org/wiki/Wikipedia:Database_reports> for a few years.
You'd be shocked what kind of stupid shit people like to fix. If you get
some automated/semi-automated reports up on the English Wikipedia (so that
people can watchlist the pages), explain what the issues are and how to
resolve them (link to MediaWiki.org documentation as necessary), advertise
the reports, and then wait, you'll find more success. This is a much better
approach than creating obscure subpages on mediawiki.org.

As Krinkle says, you need to be patient. The horribly broken pages that keep
you awake at night will generally be fixed first in a crowdsourced world.
The subtle breakage throughout the site will be fixed over time (or those
shitty phones with their shitty browsers will eventually die out in the
wild).

MZMcBride



_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
You can always have a line on the bottom of a mobile page, with "Do
the page render correctly?". And somehow use it to "flag" pages that
render incorrectly. Wooot, perhaps this flagging may even save the
user agent of the visitor using the link.



--
--
ℱin del ℳensaje.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On Thu, Jun 28, 2012 at 4:32 PM, Tei <oscar.vives@gmail.com> wrote:
> You can always have a line on the bottom of a mobile page, with  "Do
> the page render correctly?". And somehow use it to "flag" pages that
> render incorrectly.  Wooot, perhaps this flagging may even save the
> user agent of the visitor using the link.
>
>
>
> --
> --
> ℱin del ℳensaje.

You and what privacy policy/Access to nonpublic data policy are going
to process that user agent?

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
On 28 June 2012 16:37, Martijn Hoekstra <martijnhoekstra@gmail.com> wrote:
> On Thu, Jun 28, 2012 at 4:32 PM, Tei <oscar.vives@gmail.com> wrote:
>> You can always have a line on the bottom of a mobile page, with  "Do
>> the page render correctly?". And somehow use it to "flag" pages that
>> render incorrectly.  Wooot, perhaps this flagging may even save the
>> user agent of the visitor using the link.
>>
>
> You and what privacy policy/Access to nonpublic data policy are going
> to process that user agent?

Oops... :-O

I have no idea whatsoever. (Note: I will not use here the 'I was just
make a suggestion' card).

Maybe you can store information this way:
path_page | browser | browser version | number of reports

So if two persons with the exact same user agent report on page Y the
result may look like that (not actually a log, but 4 fields in a
database).
page/Y | FooBrosers | 3.21 | 2

Do this will make the law gods angry?.

--
--
ℱin del ℳensaje.

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
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
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
To summarise my position:
# I think the beta of the mobile site is a great place to __review__
the styles we have across Wikipedia and as well as resolving many of
the problems of the mobile site it would also result in a much more
maintainable Wikipedia.

# I dislike inline styles and don't think they should be supported. I
have been taught to always separate layout from HTML to avoid
duplication and keep things maintainable. (Helder thanks for the link
to the bug [1]). Currently to fix portal page layouts we have to
change all these pages >>>[2]. If they were using a class instead it
would only take a change in one wiki page (MediaWiki:Common.css). I
thus believe we should be paving a path to move away from them.

# "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.
## (The fact MediaWiki:Common.css can only be edited by admins is
another concern for me but off topic.)

# I believe people are motivated to fix things when there are agreed
deadlines and things they care about are broken rather than vice
versa. Out of date layout styles will remain out of date as no-one
probably cares about them anymore and it's not a fun or rewarding task
to fix them for anyone. On the other hand important problems such as
"why is this text not marked red in the mobile site" and working on
styling convention documentation for Wikipedia are more motivating to
fix in my opinion.

# 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.

# A report bad layout button on each page as suggested by Brion would
be highly useful but that's going to take design and coding which I
don't believe can be achieved any time soon. Currently users can use
the contact us page to report problems but I'm yet to see anyone
report bad layout.

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.

Thanks for everyones contributions so far on this long thread! I
really do appreciate this discussion and your patience with me :-).

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=15075
[2] http://www.mediawiki.org/wiki/List_of_Problematic_portal_pages_with_two_column_layouts

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
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



--
Jon Robson
http://jonrobson.me.uk
@rakugojon

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
2012/6/28 Jon Robson <jdlrobson@gmail.com>:
> # "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.

This makes no sense. Are you suggesting we create CSS classes markedX
for every one of the approx. 150 color names accepted by browsers, as
well as for every possible capitalization of these names? Because
that's what we should do to avoid having "markedRed" word but
"markedPurple" not for no user-visible reason.

(And I didn't even start to mention how this makes even less sense
semantically than inline styles. What if one text is marked with
"markedRed" and other is marked the same way despite meaning
*different* things?)

What would sort of make sense would be classes like "wrong", "no" or
"decrease", which would all have the same red color, but would mean
different things. But now we're heading for unnecessary obstacles to
editors...

-- Matma Rex

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
> What would sort of make sense would be classes like "wrong", "no" or
> "decrease", which would all have the same red color, but would mean
> different things. But now we're heading for unnecessary obstacles to
> editors...

Yes. Agreed. I just picked an arbitrary class name here. The only
point I was trying to make is moving inline styles to a class gives us
more consistency. If the color red means 'wrong' we should call the
class wrong. I wasn't for one minute suggesting we should introduce
classes for every specific color.. that would just be stupid :P

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
>> What would sort of make sense would be classes like "wrong", "no" or
>> "decrease", which would all have the same red color, but would mean
>> different things. But now we're heading for unnecessary obstacles to
>> editors...

>Yes. Agreed. I just picked an arbitrary class name here. The only point I
>was trying to make is moving inline styles to a class gives us more
>consistency. If the color red means 'wrong' we should call the class
>wrong. I wasn't for one minute suggesting we should introduce classes
>for every specific color.. that would just be stupid :P

I like the idea of class names for different things, and I don't think that
it would unduly burden the editor. As they are already using inline styles,
I think that using classes shouldn't be an undue burden. It is no harder to
say class="someClass" than it is to say style="color: #123456", in fact, I
would argue it is easier.

Thank you,
Derric Atzrott
Computer Specialist
Alizee Pathology


_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: Inline styles trouble on the mobile site [ In reply to ]
2012/6/28 Derric Atzrott <datzrott@alizeepathology.com>:
> I like the idea of class names for different things, and I don't think that
> it would unduly burden the editor.  As they are already using inline styles,
> I think that using classes shouldn't be an undue burden.  It is no harder to
> say class="someClass" than it is to say style="color: #123456", in fact, I
> would argue it is easier.

Assuming you remember all the class names, which ones will "work" and
which will not (or, worst case, you have documentation handy). People
usually already know some color names, and only need to learn the
syntax once.


-- Matma Rex

_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 2 3  View All