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?
"Is wiki admin" doesn't traditionally mean "is fully trusted not to
screw
things up deliberately" and *definitely* doesn't mean "is
trusted not to
screw things up accidentally". It would be pretty easy for an admin to
accidentally add styles which screw up the rendering of the edit form and
make it difficult to undo. And at least at the moment any such
potentially-troublesome edits are confined to one small, low-traffic
namespace. Trying to monitor recentchanges to the whole template namespace
on a large wiki for XSS is entirely impractical.
--HM