On Wed, 25 Apr 2012 04:56:32 -0700, Jon Robson jrobson@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.