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) [