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_Exte…
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(a)wikimedia.org>
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(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]