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