Inline styles trouble on the mobile site

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Inline styles trouble on the mobile site

Jon Robson-2
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Brion Vibber
On Thu, Apr 19, 2012 at 7:57 AM, Jon Robson <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Jon Robson
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Brion Vibber-3
On Apr 20, 2012 11:30 AM, "Jon Robson" <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Trevor Parscal-2
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 <[hidden email]> wrote:

> On Apr 20, 2012 11:30 AM, "Jon Robson" <[hidden email]> 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
> > [hidden email]
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Platonides
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Ryan Kaldari-2
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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Brion Vibber
On Mon, Apr 23, 2012 at 2:46 PM, Ryan Kaldari <[hidden email]>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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Jon Robson-2
In reply to this post by Platonides
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 <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Daniel Friesen-4
In reply to this post by Ryan Kaldari-2
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 <[hidden email]>  
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
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Jon Robson-2
> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Happy Melon-2
On 25 April 2012 12:56, Jon Robson <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Daniel Friesen-4
In reply to this post by Jon Robson-2
On Wed, 25 Apr 2012 04:56:32 -0700, Jon Robson <[hidden email]>  
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Jon Robson-2
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
<[hidden email]> wrote:

> On Wed, 25 Apr 2012 04:56:32 -0700, Jon Robson <[hidden email]>
> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Ryan Kaldari-2
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
> <[hidden email]>  wrote:
>> On Wed, 25 Apr 2012 04:56:32 -0700, Jon Robson<[hidden email]>
>> 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
>> [hidden email]
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> _______________________________________________
> Wikitech-l mailing list
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

MZMcBride-2
In reply to this post by Jon Robson-2
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Krinkle
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Ryan Kaldari-2
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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Tei-2
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 <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Inline styles trouble on the mobile site

Daniel Friesen-4
In reply to this post by MZMcBride-2
On Thu, 10 May 2012 11:52:17 -0700, MZMcBride <[hidden email]> 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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
123