Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Wikipedia: Wikitech

Inline styles trouble on the mobile site

 

 

First page Previous page 1 2 3 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded


jrobson at wikimedia

Apr 19, 2012, 7:57 AM

Post #1 of 59 (1680 views)
Permalink
Inline styles trouble on the mobile site

Hello!
I thought I'd reach out to the wider wikitech community to discuss a
problem we are having in the MobileFrontend extension and see if
anyone can come up with a good solution.

The MobileFrontend extension is increasingly getting [1] bugs [2]
raised [3] which are due to inline css styles present in certain wiki
articles that are written with the desktop site in mind. (Slightly off
topic there is also certain content that just doesn't work on mobile
[4])

To get an idea of some of the bugs that are present please see this bug [5].
Currently we are resorting to various !important hacks in a separate
css file [6] but this is not sustainable and does not cover everything
and ideally I would prefer that this file was not needed at all.

Solutions I have thought about so far involve the following. I am yet
to conclude on which is the best way to do this so would really
appreciate discussion...

1) scrubbing all inline styles
#########################
* in php - my worry is this would be a quite expensive operation?
* in javascript (but this doesn't help people with javascript disabled)
* would mean any nice mobile safe styling disappears :(

2) scrubbing certain inline styles
#########################
* I could imagine us scrubbing any inline styles which have not been
marked as mobile safe (e.g. anything with a class 'mobilesafe' keeps
its inline style) - this at least allows editors to use pretty styles
and encourages checking their styles on mobile

3) disallowing inline styles in wikitext output
##################################
* this is controversial as it would restrict us to defining css rules
in MediaWiki:Common.css which only admins can edit
** one could imagine pages/templates being able to maintain their own
stylesheets for desktop and mobile to allow customisations
** ResourceLoader could serve the desktop or mobile stylesheet
depending on the context

4) educating editors better about ensuring their styles work on mobile
#############################################
I'm not sure how effective/sustainable this would be and how we'd go
about doing this... but would be keen to hear your thoughts around it.

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=30887
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=36030
[3] https://bugzilla.wikimedia.org/show_bug.cgi?id=36076
[4] https://bugzilla.wikimedia.org/show_bug.cgi?id=20030
[5] https://bugzilla.wikimedia.org/show_bug.cgi?id=35704
[6] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend.git;a=blob;f=stylesheets/hacks.css;h=6fc48de650f215f7d694215cd1206ae96cce616a;hb=master

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


brion at pobox

Apr 19, 2012, 10:54 AM

Post #2 of 59 (1613 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

On Thu, Apr 19, 2012 at 7:57 AM, Jon Robson <jrobson [at] wikimedia> wrote:

> Solutions I have thought about so far involve the following. I am yet
> to conclude on which is the best way to do this so would really
> appreciate discussion...
>
> 1) scrubbing all inline styles
>

You mean removing them? That isn't super-expensive I suppose but would
damage some content by removing relevant styles.



> 2) scrubbing certain inline styles
> #########################
> * I could imagine us scrubbing any inline styles which have not been
> marked as mobile safe (e.g. anything with a class 'mobilesafe' keeps
> its inline style) - this at least allows editors to use pretty styles
> and encourages checking their styles on mobile
>

Are more styles damaging or legit? How do we know? I'd encourage keeping
all styles by default except for ones known to cause trouble...



> 3) disallowing inline styles in wikitext output
>

Kills backward compatibility with existing pages, so I'd recommend against
this.



> ** one could imagine pages/templates being able to maintain their own
> stylesheets for desktop and mobile to allow customisations
>

^^^ this would be very useful!

4) educating editors better about ensuring their styles work on mobile
> #############################################
> I'm not sure how effective/sustainable this would be and how we'd go
> about doing this... but would be keen to hear your thoughts around it.
>

Education is tough, but setting good examples in usage and documentation
always helps. Most styles are probably cut-n-pasted from elsewhere, so the
more we fix, the more new things will be fixed.


An example that I made a little effort on is the layout of portal pages. I
manually fixed up a number of portals (but not all! there's more to go),
giving them *inline styles* if any that were mobile-safe, and then using
*global styles* in MediaWiki:Common.css to provide for multi-column-style
layouts on large screens. I also redid some of the templates from using
tables to floats or inline-blocks that fit both large and small screens
reasonably.

Especially if this can be combined with <script> blocks attached to
templates -- and thus not forced to be manually rewritten -- I think that's
the way to go.

-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jdlrobson at gmail

Apr 20, 2012, 11:30 AM

Post #3 of 59 (1605 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

Brion thanks so much for the feedback

A few comments below...

> Are more styles damaging or legit? How do we know? I'd encourage keeping
> all styles by default except for ones known to cause trouble...
The problem is that styles can be extremely damaging render content
unreadable. I'd rather have a page that was ugly and readable than a
page that is trying to be pretty and unreadable.

This is personally my favourite option and for this reason I'd rather
that making content mobile friendly was an additional step.
I know this is a big undertaking but as I said readable content should
be our priority.

We could also conditionally scrub styles depending on their contents
e.g. any styles that contain known problematic properties e.g. width,
float, margin for example

> Kills backward compatibility with existing pages, so I'd recommend against
> this.
Agreed.

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

> Education is tough, but setting good examples in usage and documentation
> always helps. Most styles are probably cut-n-pasted from elsewhere, so the
> more we fix, the more new things will be fixed.
>
> An example that I made a little effort on is the layout of portal pages. I
> manually fixed up a number of portals (but not all! there's more to go),
> giving them *inline styles* if any that were mobile-safe, and then using
> *global styles* in MediaWiki:Common.css to provide for multi-column-style
> layouts on large screens. I also redid some of the templates from using
> tables to floats or inline-blocks that fit both large and small screens
> reasonably.

This is true but it is a slow process.

>
> Especially if this can be combined with <script> blocks attached to
> templates -- and thus not forced to be manually rewritten -- I think that's
> the way to go.

How would this work? Sorry I'm not sure but I'm not too clear. This
doesn't seem to solve the problem for browsers with javascript
disabled though..

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


brion at wikimedia

Apr 20, 2012, 11:53 AM

Post #4 of 59 (1601 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

On Apr 20, 2012 11:30 AM, "Jon Robson" <jdlrobson [at] gmail> wrote:
> > Especially if this can be combined with <script> blocks attached to
> > templates -- and thus not forced to be manually rewritten -- I think
that's
> > the way to go.
>
> How would this work? Sorry I'm not sure but I'm not too clear. This
> doesn't seem to solve the problem for browsers with javascript
> disabled though..
>

Sorry meant <style> there!

-- brion
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


tparscal at wikimedia

Apr 20, 2012, 1:27 PM

Post #5 of 59 (1604 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

I think you could use a multi-step process to solve this problem with the
help of the community.

1. Detect when inline styles are used on a page and add that page to a
list of pages that might have problems being rendered on mobile.
1. Make a special page that displays this list and use an edit hook
to reevaluate if a page should be on or off the list each time someone
edits it.
2. Possibly display a progress meter on the page
3. This information could be surfaced when someone with sufficient
rights to move the styles to a site style sheet loads the editor on that
page too.
2. Provide a guide for how to move inline styles into reusable style in
the site CSS and how to write special mobile versions of the styles too
(using something like MediaWiki:Mobile.css for instance)
3. Set a reasonable timeframe for when the mobile site will begin
scrubbing inline CSS from pages
4. Work with the community to reach the goal - as in: don't just dump it
on them, listen to their suggestions on what might make it easier for them
to make the switch
5. Turn on scrubbing

This might take time, but if it's facilitated like this, it can be
accelerated. I think our community will care a lot about mobile access
already, but reminding them of how many page views or unique users we have
on the mobile site already and inviting them to help make the mobile site
even better and more popular would probably help motivate people.

- Trevor

On Fri, Apr 20, 2012 at 11:53 AM, Brion Vibber <brion [at] wikimedia> wrote:

> On Apr 20, 2012 11:30 AM, "Jon Robson" <jdlrobson [at] gmail> wrote:
> > > Especially if this can be combined with <script> blocks attached to
> > > templates -- and thus not forced to be manually rewritten -- I think
> that's
> > > the way to go.
> >
> > How would this work? Sorry I'm not sure but I'm not too clear. This
> > doesn't seem to solve the problem for browsers with javascript
> > disabled though..
> >
>
> Sorry meant <style> there!
>
> -- brion
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l [at] lists
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


Platonides at gmail

Apr 20, 2012, 1:44 PM

Post #6 of 59 (1603 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

Yesterday, someone asked #wikipedia where was the separation between
style and content done on wikipedia. Users don't suddenly start to write
CSS rules in the pages themselves.
Most inline styles come from templates.

They don't write for a table:
border="2" cellpadding="4" cellspacing="0" style="margin: 0.5em 0.5em
0.5em 1em; padding: 0.5em; background: #f9f9f9; border: 1px #aaa solid;
border-collapse: collapse; font-size: 95%;
but do {{tabla bonita}}

Similarly, the infoboxes CSS don't come from the article content, but
from a template two or three layers down.

Fixing 80-90% of the inline styles should be quite simple, as it'll come
from a few templates.
The problem is to detect *when* that style gives problems on mobile.

I'm not sure what we are trying to mean with it, "it doesn't look right"
isn't simple for an algorithm to detect ;)
If we need to manually view the page, we could hardly detect it.

OTOH if we are looking for absolute values in that inline, it's simple
to do.

So what constructs are problematic for mobile? How to detect them?

Once we have such measures, it shouldn't be hard to go fixing it.
Moving css rules from inline styles to site CSS can be a step for fixing
the problems (and also recommendable for other reasons), but is not the
solution.


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


rkaldari at wikimedia

Apr 23, 2012, 2:46 PM

Post #7 of 59 (1590 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

I would like to second what Platonides has said. It's important to
understand that 99% of the inline CSS comes from templates. Stripping
the CSS is probably not a good option, as the results would be rather
unpredictable (some of the templates are heavily dependent on CSS, some
are not). Unfortunately, there isn't currently a good solution to this,
as the way templates are constructed only allows for inline CSS (without
spamming Common.css). My preferred solution would be to start allowing
<style> tags within the Template namespace. Then people could create
real CSS logic for templates (including mobile styling with CSS
queries). There is, however, the slight problem that browser-makers and
the W3C don't quite see eye-to-eye on implementing <style> tags in the
body. According to the W3C, it is invalid to use <style> in the body
unless it is scoped (i.e. uses the scoped attribute). All current
browser-makers, however, allow <style> in the body and none of them
support the scoped attribute. In other words, we would be pretty much
guaranteed to break our W3C validation for almost every page, but as far
as I can tell, this is already the case anyway.

Ryan Kaldari

On 4/20/12 1:44 PM, Platonides wrote:
> Yesterday, someone asked #wikipedia where was the separation between
> style and content done on wikipedia. Users don't suddenly start to write
> CSS rules in the pages themselves.
> Most inline styles come from templates.
>
> They don't write for a table:
> border="2" cellpadding="4" cellspacing="0" style="margin: 0.5em 0.5em
> 0.5em 1em; padding: 0.5em; background: #f9f9f9; border: 1px #aaa solid;
> border-collapse: collapse; font-size: 95%;
> but do {{tabla bonita}}
>
> Similarly, the infoboxes CSS don't come from the article content, but
> from a template two or three layers down.
>
> Fixing 80-90% of the inline styles should be quite simple, as it'll come
> from a few templates.
> The problem is to detect *when* that style gives problems on mobile.
>
> I'm not sure what we are trying to mean with it, "it doesn't look right"
> isn't simple for an algorithm to detect ;)
> If we need to manually view the page, we could hardly detect it.
>
> OTOH if we are looking for absolute values in that inline, it's simple
> to do.
>
> So what constructs are problematic for mobile? How to detect them?
>
> Once we have such measures, it shouldn't be hard to go fixing it.
> Moving css rules from inline styles to site CSS can be a step for fixing
> the problems (and also recommendable for other reasons), but is not the
> solution.
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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


brion at pobox

Apr 23, 2012, 2:49 PM

Post #8 of 59 (1594 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

On Mon, Apr 23, 2012 at 2:46 PM, Ryan Kaldari <rkaldari [at] wikimedia>wrote:

> I would like to second what Platonides has said. It's important to
> understand that 99% of the inline CSS comes from templates. Stripping the
> CSS is probably not a good option, as the results would be rather
> unpredictable (some of the templates are heavily dependent on CSS, some are
> not). Unfortunately, there isn't currently a good solution to this, as the
> way templates are constructed only allows for inline CSS (without spamming
> Common.css). My preferred solution would be to start allowing <style> tags
> within the Template namespace. Then people could create real CSS logic for
> templates (including mobile styling with CSS queries). There is, however,
> the slight problem that browser-makers and the W3C don't quite see
> eye-to-eye on implementing <style> tags in the body. According to the W3C,
> it is invalid to use <style> in the body unless it is scoped (i.e. uses the
> scoped attribute). All current browser-makers, however, allow <style> in
> the body and none of them support the scoped attribute. In other words, we
> would be pretty much guaranteed to break our W3C validation for almost
> every page, but as far as I can tell, this is already the case anyway.
>

I'd LOOOOOVE to use scoped <style>s, but as you note they're just not
supported yet.

It may make the most sense to have an extension (like the existing CSS
extension?) that lets you specify style blocks in a page or template, and
have it shove them into the header output for the page.

We'd need to make sure of a few things:
* appropriate scrubbing of script or url references
* make sure that we *do* ship the styles with pages for mobile....
* ... make sure that there's sane separation of base & large-screen styles ?

Potentially we can have something that's separate from @media queries but
lets us specify "don't use this style on mobile".

-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


jrobson at wikimedia

Apr 23, 2012, 3:51 PM

Post #9 of 59 (1603 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

In terms of detection we could suggest when they might be a problem
however if we were to use an algorithm it is likely to highlight
mobile safe pages as having a problem. For instance if a page had an
inline style width:300px; this could cause problems on a mobile device
with a window width of less than 300px but on other devices it would
appear fine.

If we are to identify problematic pages I'd prefer some kind of
crowd-sourced approach where a reader can report a page as having
problems. If would then be good to see which of those pages share
templates. I think Platonides is right in that most inline styles come
from templates so an approach as suggested by Trevor does sound quite
sensible and realistic but as Trevor says it will take time.

FWIW problematic CSS that I have identified so far include:
* Margins and paddings that are not %s e.g. -1px 21em 0 0;
* Any fixed widths can cause problems e.g. width:300px;
* Any use of top, left, right, bottom which uses a pixel value e.g. left: 300px;
* Any use of float or clear - the mobile site does strip certain
content (at the moment) that is known to cause problems. These items
might be clearing these floats and without them could lead to
problems.
* -webkit-column-count greater than 1 can cause issues (tends to be
used mostly in references and notes sections)

On a side note there is also problematic HTML that would benefit from
being able to be styled via css rather than inline styles. The one I
can think of off of the top of my head is image maps as these rely on
fixed widths.

Although I think a stylesheet per wiki page would be great I can see
problems in this in terms of ResourceLoader working out where to
gather styles from. I'm a bit worried about allowing style tags in the
template namespace as I'd like us one day to W3C validate :-) and
personally I'd worry that mixing wikitext and css could make templates
even more hard to decipher. I think this would benefit from a clear
separation... Could templates have a CSS page (similar to how each
page has a talk page)? This 'CSS page' could then be served either as
a style tag in the head of the wiki page or even better pushed into
ResourceLoader.

I think the solution we seem to be arriving at (please correct me if
I'm wrong) is...
* Allow users to define css rules rather than inline css
* Clean up templates, possibly allowing flagging of templates to make
this job easier
* In the long term considering the turning off of inline styles on the
mobile site

Note that already the mobile site has a mobile class on the body tag
[1] to allow users to specifically target the mobile site (note this
possibly should be on the html tag)

[1] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MobileFrontend.git;a=commit;h=707c2ef3

On Fri, Apr 20, 2012 at 9:44 PM, Platonides <Platonides [at] gmail> wrote:
> Yesterday, someone asked #wikipedia where was the separation between
> style and content done on wikipedia. Users don't suddenly start to write
> CSS rules in the pages themselves.
> Most inline styles come from templates.
>
> They don't write for a table:
>  border="2" cellpadding="4" cellspacing="0"  style="margin: 0.5em 0.5em
> 0.5em 1em; padding: 0.5em; background: #f9f9f9; border: 1px #aaa solid;
> border-collapse: collapse; font-size: 95%;
>  but do {{tabla bonita}}
>
> Similarly, the infoboxes CSS don't come from the article content, but
> from a template two or three layers down.
>
> Fixing 80-90% of the inline styles should be quite simple, as it'll come
> from a few templates.
> The problem is to detect *when* that style gives problems on mobile.
>
> I'm not sure what we are trying to mean with it, "it doesn't look right"
> isn't simple for an algorithm to detect ;)
> If we need to manually view the page, we could hardly detect it.
>
> OTOH if we are looking for absolute values in that inline, it's  simple
> to do.
>
> So what constructs are problematic for mobile? How to detect them?
>
> Once we have such measures, it shouldn't be hard to go fixing it.
> Moving css rules from inline styles to site CSS can be a step for fixing
> the problems (and also recommendable for other reasons), but is not the
> solution.
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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


lists at nadir-seen-fire

Apr 23, 2012, 5:15 PM

Post #10 of 59 (1598 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

We already don't validate. There's no point to trying to conform to a
validator when the spec/validator is wrong. And we already have cases like
that.
Anyways, technically you could already use scoped anyways. Just add the
scoped attribute. Don't use css that applies outside the content area. And
then it'll validate, it'll work in browsers, and when browsers actually
implement scoped they'll start restricting the scope.

That said I'm not sure about the security standpoint of this. Naturally
you have to strip out all expression() and url() sets. Also considering
the fact that image() is also being added and that should probably be
stripped. You can't html escape <>'s because in HTML <style> is implied to
be CDATA; but you also can't leave them alone. And you have to be wary
about the fact that trying to blacklist tags may leave potential XSS
vectors open. So you'll have to css escape them and hope that works.
But after you've dealt with all the XSS issues; you've opened up the
ability to completely destroy the UI from within WikiText. In ways even
worse than the tricks attempting to simply cover the whole UI with a div.
Those tricks being ones you could technically eliminate by using
overflow+relative on the content area and disallowing position: fixed;
(The only thing in the way of that right now is WP's stupid page icon
hack).

My hope was to one day add a proper parser to RL:
https://www.mediawiki.org/wiki/Requests_for_comment/ResourceLoader_CSS_Extensions

It would actually understand css. So it could make it completely safe to
allow css inside WikiText. Stripping out unknown things that open up
holes. And automatically prefixing selectors. It would also cut off the
need for ridiculous things like verbosely repeating vendor prefixes or
using template hacks. And also allow the use of background-image for files
uploaded to the wiki.

On Mon, 23 Apr 2012 14:46:20 -0700, Ryan Kaldari <rkaldari [at] wikimedia>
wrote:

> I would like to second what Platonides has said. It's important to
> understand that 99% of the inline CSS comes from templates. Stripping
> the CSS is probably not a good option, as the results would be rather
> unpredictable (some of the templates are heavily dependent on CSS, some
> are not). Unfortunately, there isn't currently a good solution to this,
> as the way templates are constructed only allows for inline CSS (without
> spamming Common.css). My preferred solution would be to start allowing
> <style> tags within the Template namespace. Then people could create
> real CSS logic for templates (including mobile styling with CSS
> queries). There is, however, the slight problem that browser-makers and
> the W3C don't quite see eye-to-eye on implementing <style> tags in the
> body. According to the W3C, it is invalid to use <style> in the body
> unless it is scoped (i.e. uses the scoped attribute). All current
> browser-makers, however, allow <style> in the body and none of them
> support the scoped attribute. In other words, we would be pretty much
> guaranteed to break our W3C validation for almost every page, but as far
> as I can tell, this is already the case anyway.
>
> Ryan Kaldari
>
> On 4/20/12 1:44 PM, Platonides wrote:
>> Yesterday, someone asked #wikipedia where was the separation between
>> style and content done on wikipedia. Users don't suddenly start to write
>> CSS rules in the pages themselves.
>> Most inline styles come from templates.
>>
>> They don't write for a table:
>> border="2" cellpadding="4" cellspacing="0" style="margin: 0.5em 0.5em
>> 0.5em 1em; padding: 0.5em; background: #f9f9f9; border: 1px #aaa solid;
>> border-collapse: collapse; font-size: 95%;
>> but do {{tabla bonita}}
>>
>> Similarly, the infoboxes CSS don't come from the article content, but
>> from a template two or three layers down.
>>
>> Fixing 80-90% of the inline styles should be quite simple, as it'll come
>> from a few templates.
>> The problem is to detect *when* that style gives problems on mobile.
>>
>> I'm not sure what we are trying to mean with it, "it doesn't look right"
>> isn't simple for an algorithm to detect ;)
>> If we need to manually view the page, we could hardly detect it.
>>
>> OTOH if we are looking for absolute values in that inline, it's simple
>> to do.
>>
>> So what constructs are problematic for mobile? How to detect them?
>>
>> Once we have such measures, it shouldn't be hard to go fixing it.
>> Moving css rules from inline styles to site CSS can be a step for fixing
>> the problems (and also recommendable for other reasons), but is not the
>> solution.
>>
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

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


jrobson at wikimedia

Apr 25, 2012, 4:56 AM

Post #11 of 59 (1589 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

> We already don't validate. There's no point to trying to conform to a
> validator when the spec/validator is wrong. And we already have cases like
> that.

I think we should try to validate though mostly for future proofing...

> Anyways, technically you could already use scoped anyways. Just add the
> scoped attribute. Don't use css that applies outside the content area. And
> then it'll validate, it'll work in browsers, and when browsers actually
> implement scoped they'll start restricting the scope.
<snip>
> But after you've dealt with all the XSS issues; you've opened up the ability
> to completely destroy the UI from within WikiText. In ways even worse than
> the tricks attempting to simply cover the whole UI with a div. Those tricks
> being ones you could technically eliminate by using overflow+relative on the
> content area and disallowing position: fixed; (The only thing in the way of
> that right now is WP's stupid page icon hack).
>
I think if we restricted css to templates that only trusted admins can
edit then these problems goes away somewhat no?

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


happy.melon.wiki at gmail

Apr 25, 2012, 8:05 AM

Post #12 of 59 (1634 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

On 25 April 2012 12:56, Jon Robson <jrobson [at] wikimedia> wrote:

> > We already don't validate. There's no point to trying to conform to a
> > validator when the spec/validator is wrong. And we already have cases
> like
> > that.
>
> I think we should try to validate though mostly for future proofing...
>
> > Anyways, technically you could already use scoped anyways. Just add the
> > scoped attribute. Don't use css that applies outside the content area.
> And
> > then it'll validate, it'll work in browsers, and when browsers actually
> > implement scoped they'll start restricting the scope.
> <snip>
> > But after you've dealt with all the XSS issues; you've opened up the
> ability
> > to completely destroy the UI from within WikiText. In ways even worse
> than
> > the tricks attempting to simply cover the whole UI with a div. Those
> tricks
> > being ones you could technically eliminate by using overflow+relative on
> the
> > content area and disallowing position: fixed; (The only thing in the way
> of
> > that right now is WP's stupid page icon hack).
> >
> I think if we restricted css to templates that only trusted admins can
> edit then these problems goes away somewhat no?
>
> "Is wiki admin" doesn't traditionally mean "is fully trusted not to screw
things up deliberately" and *definitely* doesn't mean "is trusted not to
screw things up accidentally". It would be pretty easy for an admin to
accidentally add styles which screw up the rendering of the edit form and
make it difficult to undo. And at least at the moment any such
potentially-troublesome edits are confined to one small, low-traffic
namespace. Trying to monitor recentchanges to the whole template namespace
on a large wiki for XSS is entirely impractical.

--HM
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


lists at nadir-seen-fire

Apr 25, 2012, 12:32 PM

Post #13 of 59 (1586 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

On Wed, 25 Apr 2012 04:56:32 -0700, Jon Robson <jrobson [at] wikimedia>
wrote:

>> We already don't validate. There's no point to trying to conform to a
>> validator when the spec/validator is wrong. And we already have cases
>> like
>> that.
>
> I think we should try to validate though mostly for future proofing...
>
>> Anyways, technically you could already use scoped anyways. Just add the
>> scoped attribute. Don't use css that applies outside the content area.
>> And
>> then it'll validate, it'll work in browsers, and when browsers actually
>> implement scoped they'll start restricting the scope.
> <snip>
>> But after you've dealt with all the XSS issues; you've opened up the
>> ability
>> to completely destroy the UI from within WikiText. In ways even worse
>> than
>> the tricks attempting to simply cover the whole UI with a div. Those
>> tricks
>> being ones you could technically eliminate by using overflow+relative
>> on the
>> content area and disallowing position: fixed; (The only thing in the
>> way of
>> that right now is WP's stupid page icon hack).
>>
> I think if we restricted css to templates that only trusted admins can
> edit then these problems goes away somewhat no?

Sure. Except since admins can already edit Common.css you just completely
destroyed the point of putting css in WikiText. And you've introduced
unstable behavior we don't want where the protection state of an article
affects the presentation of the page content. If you temp protect a
template all of a sudden when the protection expires the content changes
in style. Additionally we don't necessarily purge parser cache on
unprotect or tie protection state into the parser options/output. So such
a thing bridges on making the parser even less self-contained.

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

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


jrobson at wikimedia

May 10, 2012, 10:56 AM

Post #14 of 59 (1568 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

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.

Trevor earlier suggested a great course of action where we evaluate if
pages have problems and fix them up to be mobile friendly. Trevor
suggested we should work with the community to reach this goal of
moving important inline styles into stylesheets and suggested having a
timeframe to do so after which we could scrub all inline styles from
the mobile version of the site.

I've also heard that inline styles are highly useful and that since
only admins can edit MediaWiki/Common.css it seems unfair to prevent
inline styles altogether and also it goes without saying that we are
keen to keep backwards compatibility.

So here is my concrete suggestion. I welcome all feedback on this -
positive and negative. At this current time this is just a proposal!

1) We turn on inline style scrubbing in the beta of the __mobile
site__ (for those that don't know this is an opt in service [1] and
won't effect anyone who has no opted in). We invite community members
to join the beta and help us survey and fix the damage. Since the
inline style scrubbing only applies to the beta - it's business as
usual elsewhere. The desktop site is not effected in any way.

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:
<div id='foo1' style="/*@mobilesafe*/padding:10px;"></div>
<div id='foo2'></div>
This is **key** as it allows template admins to do one of two things -
move the inline styles into MediaWiki:Common.css (which allows us to
easily fix them for mobile much easier and without !important rules)
or prefix inline styles with @mobilesafe after they have verified they
are purely presentational (and work on mobile).

3) We give community members a fixed time -e.g. 2/3 months - after
which we will make this the default. This allows plenty of time for us
to work together to fix inline styles across the site.

4) Obviously we will have a wiki page with guidance notes where we can
report pitfalls as we discover in inline styles on the mobile site
with explanations of how to fix to make this transition as smooth as
possible.

After this time anyone unfamiliar/not bothered with making content
mobile safe can still add inline styles to the desktop site but they
will not touch the mobile site. We will achieved a brilliant thing of
making our content accessible to our growing [2] mobile audience

Thoughts? Is this workable?
Jon

[1] http://blog.wikimedia.org/2011/10/27/wikimedia-mobile-opt-in-beta/
[2] https://blog.wikimedia.org/2012/05/03/mobile-milestone-two-billion-page-views/

On Wed, Apr 25, 2012 at 8:32 PM, Daniel Friesen
<lists [at] nadir-seen-fire> wrote:
> On Wed, 25 Apr 2012 04:56:32 -0700, Jon Robson <jrobson [at] wikimedia>
> wrote:
>
>>> We already don't validate. There's no point to trying to conform to a
>>> validator when the spec/validator is wrong. And we already have cases
>>> like
>>> that.
>>
>>
>> I think we should try to validate though mostly for future proofing...
>>
>>> Anyways, technically you could already use scoped anyways. Just add the
>>> scoped attribute. Don't use css that applies outside the content area.
>>> And
>>> then it'll validate, it'll work in browsers, and when browsers actually
>>> implement scoped they'll start restricting the scope.
>>
>> <snip>
>>>
>>> But after you've dealt with all the XSS issues; you've opened up the
>>> ability
>>> to completely destroy the UI from within WikiText. In ways even worse
>>> than
>>> the tricks attempting to simply cover the whole UI with a div. Those
>>> tricks
>>> being ones you could technically eliminate by using overflow+relative on
>>> the
>>> content area and disallowing position: fixed; (The only thing in the way
>>> of
>>> that right now is WP's stupid page icon hack).
>>>
>> I think if we restricted css to templates that only trusted admins can
>> edit then these problems goes away somewhat no?
>
>
> Sure. Except since admins can already edit Common.css you just completely
> destroyed the point of putting css in WikiText. And you've introduced
> unstable behavior we don't want where the protection state of an article
> affects the presentation of the page content. If you temp protect a template
> all of a sudden when the protection expires the content changes in style.
> Additionally we don't necessarily purge parser cache on unprotect or tie
> protection state into the parser options/output. So such a thing bridges on
> making the parser even less self-contained.
>
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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


rkaldari at wikimedia

May 10, 2012, 11:46 AM

Post #15 of 59 (1611 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

This sounds like it might be a workable solution. There are a couple of
potential pitfalls, however, mainly due to the fact that we're probably
talking about thousands of templates here. First, we should establish
some guidelines on when in makes sense to move styles to Common.css,
otherwise we might end up spamming it with tons of new rules that aren't
actually that useful. Second, we should build a list of the templates
with the highest transclusion numbers so that we can focus QA on those
templates rather than just hoping that people stumble across them on
mobile beta.

I think this would be a pretty huge clean-up task, so if we go down this
road, we should recruit members of the community to act as leaders for
the effort. We might also need more than 2 months for a realistic timeframe.

Ryan Kaldari

On 5/10/12 10:56 AM, 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.
>
> Trevor earlier suggested a great course of action where we evaluate if
> pages have problems and fix them up to be mobile friendly. Trevor
> suggested we should work with the community to reach this goal of
> moving important inline styles into stylesheets and suggested having a
> timeframe to do so after which we could scrub all inline styles from
> the mobile version of the site.
>
> I've also heard that inline styles are highly useful and that since
> only admins can edit MediaWiki/Common.css it seems unfair to prevent
> inline styles altogether and also it goes without saying that we are
> keen to keep backwards compatibility.
>
> So here is my concrete suggestion. I welcome all feedback on this -
> positive and negative. At this current time this is just a proposal!
>
> 1) We turn on inline style scrubbing in the beta of the __mobile
> site__ (for those that don't know this is an opt in service [1] and
> won't effect anyone who has no opted in). We invite community members
> to join the beta and help us survey and fix the damage. Since the
> inline style scrubbing only applies to the beta - it's business as
> usual elsewhere. The desktop site is not effected in any way.
>
> 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:
> <div id='foo1' style="/*@mobilesafe*/padding:10px;"></div>
> <div id='foo2'></div>
> This is **key** as it allows template admins to do one of two things -
> move the inline styles into MediaWiki:Common.css (which allows us to
> easily fix them for mobile much easier and without !important rules)
> or prefix inline styles with @mobilesafe after they have verified they
> are purely presentational (and work on mobile).
>
> 3) We give community members a fixed time -e.g. 2/3 months - after
> which we will make this the default. This allows plenty of time for us
> to work together to fix inline styles across the site.
>
> 4) Obviously we will have a wiki page with guidance notes where we can
> report pitfalls as we discover in inline styles on the mobile site
> with explanations of how to fix to make this transition as smooth as
> possible.
>
> After this time anyone unfamiliar/not bothered with making content
> mobile safe can still add inline styles to the desktop site but they
> will not touch the mobile site. We will achieved a brilliant thing of
> making our content accessible to our growing [2] mobile audience
>
> Thoughts? Is this workable?
> Jon
>
> [1] http://blog.wikimedia.org/2011/10/27/wikimedia-mobile-opt-in-beta/
> [2] https://blog.wikimedia.org/2012/05/03/mobile-milestone-two-billion-page-views/
>
> On Wed, Apr 25, 2012 at 8:32 PM, Daniel Friesen
> <lists [at] nadir-seen-fire> wrote:
>> On Wed, 25 Apr 2012 04:56:32 -0700, Jon Robson<jrobson [at] wikimedia>
>> wrote:
>>
>>>> We already don't validate. There's no point to trying to conform to a
>>>> validator when the spec/validator is wrong. And we already have cases
>>>> like
>>>> that.
>>>
>>> I think we should try to validate though mostly for future proofing...
>>>
>>>> Anyways, technically you could already use scoped anyways. Just add the
>>>> scoped attribute. Don't use css that applies outside the content area.
>>>> And
>>>> then it'll validate, it'll work in browsers, and when browsers actually
>>>> implement scoped they'll start restricting the scope.
>>> <snip>
>>>> But after you've dealt with all the XSS issues; you've opened up the
>>>> ability
>>>> to completely destroy the UI from within WikiText. In ways even worse
>>>> than
>>>> the tricks attempting to simply cover the whole UI with a div. Those
>>>> tricks
>>>> being ones you could technically eliminate by using overflow+relative on
>>>> the
>>>> content area and disallowing position: fixed; (The only thing in the way
>>>> of
>>>> that right now is WP's stupid page icon hack).
>>>>
>>> I think if we restricted css to templates that only trusted admins can
>>> edit then these problems goes away somewhat no?
>>
>> Sure. Except since admins can already edit Common.css you just completely
>> destroyed the point of putting css in WikiText. And you've introduced
>> unstable behavior we don't want where the protection state of an article
>> affects the presentation of the page content. If you temp protect a template
>> all of a sudden when the protection expires the content changes in style.
>> Additionally we don't necessarily purge parser cache on unprotect or tie
>> protection state into the parser options/output. So such a thing bridges on
>> making the parser even less self-contained.
>>
>>
>> --
>> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
>>
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l [at] lists
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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


z at mzmcbride

May 10, 2012, 11:52 AM

Post #16 of 59 (1561 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

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
highlighting).

> 1) We turn on inline style scrubbing in the beta of the __mobile
> site__ (for those that don't know this is an opt in service [1] and
> won't effect anyone who has no opted in). We invite community members
> to join the beta and help us survey and fix the damage. Since the
> inline style scrubbing only applies to the beta - it's business as
> usual elsewhere. The desktop site is not effected in any way.

Have you found a page (any page) that doesn't use any inline styling? It
sounds like you're suggesting breaking every page on the mobile site. It's
trivial to strip all inline styling, but I can't imagine that will improve
the mobile experience for anyone.

> 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:
> <div id='foo1' style="/*@mobilesafe*/padding:10px;"></div>
> <div id='foo2'></div>
> This is **key** as it allows template admins to do one of two things -
> move the inline styles into MediaWiki:Common.css (which allows us to
> easily fix them for mobile much easier and without !important rules)
> or prefix inline styles with @mobilesafe after they have verified they
> are purely presentational (and work on mobile).

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.

I'm still having difficulty understanding your overall problem. "margin:
-1px 21em 0 0;" is pretty stupid code, regardless of device. Specific
problems like this are easy enough to address. Is there any reason for the
proposed additional complexity? Stripping all inline styling is "cut off
your arm because your nails need to be cut" thinking.

MZMcBride



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


krinklemail at gmail

May 10, 2012, 7:13 PM

Post #17 of 59 (1563 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

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
> highlighting).
>


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
in the past. Think of new browser releases, monitor size changes, CSS/JavaScript
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[1]) 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


[1] Note that at the time (maybe still today) those [expand]/[collapse] buttons
from those Wikipedia templates are shown regardless of javascript (which is
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
https://lists.wikimedia.org/mailman/listinfo/wikitech-l


rkaldari at wikimedia

May 11, 2012, 1:24 AM

Post #18 of 59 (1609 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

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.

Ryan Kaldari

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
>> highlighting).
>>
>
> 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
> in the past. Think of new browser releases, monitor size changes, CSS/JavaScript
> 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[1]) 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
>
>
> [1] Note that at the time (maybe still today) those [expand]/[collapse] buttons
> from those Wikipedia templates are shown regardless of javascript (which is
> 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
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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


oscar.vives at gmail

May 11, 2012, 2:17 AM

Post #19 of 59 (1554 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

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)


On 11 May 2012 10:24, Ryan Kaldari <rkaldari [at] wikimedia> 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.

--
--
ℱin del ℳensaje.

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


lists at nadir-seen-fire

May 11, 2012, 5:18 AM

Post #20 of 59 (1568 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

On Thu, 10 May 2012 11:52:17 -0700, MZMcBride <z [at] 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.

Saying that inline styles are present on over 99% pages on en.wp is a
logical fallacy.
99% of articles may have inline styles in their output but the only pages
that are an actual issue are ones where the inline styles are in the
content themselves not in embedded templates.
If we have 1000 pages with 1 template and inline styles inside the
template, then we only have to fix the one template. NOT the 1000 pages.

Don't underestimate template changes or bots.

> 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
> highlighting).
>
>> 1) We turn on inline style scrubbing in the beta of the __mobile
>> site__ (for those that don't know this is an opt in service [1] and
>> won't effect anyone who has no opted in). We invite community members
>> to join the beta and help us survey and fix the damage. Since the
>> inline style scrubbing only applies to the beta - it's business as
>> usual elsewhere. The desktop site is not effected in any way.
>
> Have you found a page (any page) that doesn't use any inline styling? It
> sounds like you're suggesting breaking every page on the mobile site.
> It's
> trivial to strip all inline styling, but I can't imagine that will
> improve
> the mobile experience for anyone.

Selection of pages from Special:Random:
- https://en.wikipedia.org/wiki/Vic_Belsham - No explicit inline styles
- https://en.wikipedia.org/wiki/Cecil_Hunt - No explicit inline styles
- https://en.wikipedia.org/wiki/Hazeliidae - No explicit inline styles
- https://en.wikipedia.org/wiki/Maid_of_Iowa - No explicit inline styles
- https://en.wikipedia.org/wiki/James_Herries_Beattie - No explicit inline
styles
- https://en.wikipedia.org/wiki/Jack_McCafferty - No explicit inline styles
- https://en.wikipedia.org/wiki/Adams-Pickering_Block - No explicit inline
styles
-
https://en.wikipedia.org/wiki/Live_at_the_Fillmore_%28The_Residents_album%29
- No explicit inline styles
- https://en.wikipedia.org/wiki/Compact_Muon_Solenoid - One html4
border="1"
-
https://en.wikipedia.org/wiki/List_of_Indiana_state_historical_markers_in_Tipton_County
- width: 98%;

>> 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:
>> <div id='foo1' style="/*@mobilesafe*/padding:10px;"></div>
>> <div id='foo2'></div>
>> This is **key** as it allows template admins to do one of two things -
>> move the inline styles into MediaWiki:Common.css (which allows us to
>> easily fix them for mobile much easier and without !important rules)
>> or prefix inline styles with @mobilesafe after they have verified they
>> are purely presentational (and work on mobile).
>
> 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.
>
> I'm still having difficulty understanding your overall problem. "margin:
> -1px 21em 0 0;" is pretty stupid code, regardless of device. Specific
> problems like this are easy enough to address. Is there any reason for
> the
> proposed additional complexity? Stripping all inline styling is "cut off
> your arm because your nails need to be cut" thinking.
>
> MZMcBride


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

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


maxsem.wiki at gmail

May 11, 2012, 6:17 AM

Post #21 of 59 (1551 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

On 11.05.2012, 12:24 Ryan 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.

Such functionality already exists, even with the same class name ;-8
However, there's a problem with this code[1] that prevents it from
working in all situations.

----
[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=36742

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


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


jdlrobson at gmail

May 11, 2012, 8:02 AM

Post #22 of 59 (1558 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

It would be good if possible to get a more accurate feel for what
percentage of articles use inline styles.
e.g. articles that contain style= vs articles that don't
This would help us get a better idea of what we are dealing with.

The example given of highlighting - I understand the need for
something like this - but this sounds like it would be better off as a
global style in MediaWiki:Common.css so highlighting is consistent
across all wiki articles. If one template is highlighting text in
yellow and another in orange and they are trying to emphasise the same
thing this is not so good in my opinion!

My main issue with inline styles is the mixing of css and html. I
still think it would be much more manageable if templates were able to
manage their own stylesheets instead and use classes for styling
purposes but as I understand this could be a tricky manoeuvre.

I don't think a nomobile class would help here - if something is
broken now on the mobile site why would someone add a nomobile class
rather than fixing the inline style? Also rendering the content badly
is probably better than not rendering it at all.

I think our main goal should be an agreed way to cleanup these inline
styles effectively. The current procedure for cleaning these up is not
working in my opinion as bug 36076 [1] was raised in the middle of
April and a duplicate bug 36750 [2] was raised almost half a month
later despite some discussion around the subject.

The example of the track listings is caused by an inline style
margin:-1px 21em 0 0; - there is no reason this should not be used on
the desktop site - but obviously this is not fit for purpose on the
mobile site. If this was styled via a stylesheet (either
MediaWiki:Common.css or other) these rules can be optimised for mobile
(the mobile site body tag carries a class 'mobile' and there are of
course media queries)

I still think the turning off inline styles on the beta has merit as
it provides us an effective method of working out which styles are
essential to both mobile and desktop and should be in stylesheets
rather than existing as inline styles. If we are not keen on the
@mobilesafe annotation there is no reason we have to go down that
route.

So another course of action might be:
1) scrub inline styles in the beta of the mobile site
2) assess damage and shift all important and generic inline styles to
stylesheets - this will take time but is a very worthwhile community
exercise (in my opinion this would be anything involving floats,
margins, padding and fixed widths)
3) add mobile specific styles for these to stylesheets
4) Turn off inline style scrubbing in beta
5) Introduce guidelines for when things should be inline styles and
when not to try to prevent us getting to this point again in the
future
6 (long term) Deprecate the need for inline styles by allowing css
declarations within wikitext.

[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=36076
[2] https://bugzilla.wikimedia.org/show_bug.cgi?id=36740

On Fri, May 11, 2012 at 2:17 PM, Max Semenik <maxsem.wiki [at] gmail> wrote:
> On 11.05.2012, 12:24 Ryan 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.
>
> Such functionality already exists, even with the same class name ;-8
> However, there's a problem with this code[1] that prevents it from
> working in all situations.
>
> ----
> [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=36742
>
> --
> Best regards,
>  Max Semenik ([[User:MaxSem]])
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l [at] lists
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



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

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


mail at tgries

May 11, 2012, 8:48 AM

Post #23 of 59 (1566 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

Am 11.05.2012 10:24, schrieb Ryan Kaldari:
> What about this idea: We could introduce a new CSS class called
> 'nomobile' that functioned similarly to 'noprint' —

as we are talking about this - yes, I know [1]) -

in a previous posting on #mediawiki_

I already asked to introduce a new class
_
* .noscreen*

to disable elements when rendered on */screen /*media, similar to .noprint

.noscreen {
display: none;
}

In older MW versions I could easily add that. In the current MW core, I
did not find a way to get it working.
Now knowing [1], it might be a consequence from that.

Perhaps anyone can help here, too ?


[1] https://bugzilla.wikimedia.org/show_bug.cgi?id=36742
Elements with blacklisted class get removed only if it's their only class
Attachments: signature.asc (0.48 KB)


wicke at wikidev

May 11, 2012, 3:14 PM

Post #24 of 59 (1533 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

On 05/11/2012 05:02 PM, Jon Robson wrote:
> It would be good if possible to get a more accurate feel for what
> percentage of articles use inline styles.
> e.g. articles that contain style= vs articles that don't
> This would help us get a better idea of what we are dealing with.

I just grepped an enwiki dump using the dumpGrepper tool in
extensions/VisualEditor/tests/parser:

zcat enwiki-latest-pages-articles.xml.gz \
| node dumpGrepper.js "\bstyle\s*=\s*['\"]"

(..all matches..)
################################################
Total revisions: 11687077
Total matches: 675254
Ratio: 5.77%
################################################

This includes templates, and counts all matches vs. all revisions- the
number of matched articles will be even lower.

So it is safe to assume that most content pages don't contain any inline
styles.

The bzip-compressed (1.2GB uncompressed) output can soon be found here:
http://dev.wikidev.net/gabriel/tmp/style.txt.bz2

Gabriel


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


z at mzmcbride

May 11, 2012, 5:26 PM

Post #25 of 59 (1537 views)
Permalink
Re: Inline styles trouble on the mobile site [In reply to]

Daniel Friesen wrote:
> Saying that inline styles are present on over 99% pages on en.wp is a
> logical fallacy.
> 99% of articles may have inline styles in their output but the only pages
> that are an actual issue are ones where the inline styles are in the
> content themselves not in embedded templates.
> If we have 1000 pages with 1 template and inline styles inside the
> template, then we only have to fix the one template. NOT the 1000 pages.
>
> Don't underestimate template changes or bots.

I don't underestimate. Yes, you can make a mess and then clean it up. It
doesn't make the process any more enjoyable. And the context was disabling
(all) inline styling. My point was that currently that would break nearly
every page in some way.

>> 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
>> highlighting).
>>
>>> 1) We turn on inline style scrubbing in the beta of the __mobile
>>> site__ (for those that don't know this is an opt in service [1] and
>>> won't effect anyone who has no opted in). We invite community members
>>> to join the beta and help us survey and fix the damage. Since the
>>> inline style scrubbing only applies to the beta - it's business as
>>> usual elsewhere. The desktop site is not effected in any way.
>>
>> Have you found a page (any page) that doesn't use any inline styling? It
>> sounds like you're suggesting breaking every page on the mobile site.
>> It's
>> trivial to strip all inline styling, but I can't imagine that will
>> improve
>> the mobile experience for anyone.
>
> Selection of pages from Special:Random:
> - https://en.wikipedia.org/wiki/Vic_Belsham - No explicit inline styles

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">

As far as I understand it, this is a conversation about stripping all inline
styling, not just styling from the articles themselves. Which is what I
think these examples are?

Back on point, I think nomobile is a good idea. People have been using
multiple classes as a hack to force content to be rendered, even:
<https://bugzilla.wikimedia.org/show_bug.cgi?id=29157#c2>.

MZMcBride



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

First page Previous page 1 2 3 Next page Last page  View All Wikipedia wikitech RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.