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]
On Wed, Apr 25, 2012 at 8:32 PM, Daniel Friesen
<lists(a)nadir-seen-fire.com> wrote:
On Wed, 25 Apr 2012 04:56:32 -0700, Jon
Robson<jrobson(a)wikimedia.org>
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org