W3C home > Mailing lists > Public > www-style@w3.org > March 2014

Re: [cssom] CSSNamespaceRule

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 19 Mar 2014 09:55:40 -0400
Message-ID: <5329A1DC.8060101@mit.edu>
To: Simon Pieters <simonp@opera.com>, www-style@w3.org, Daniel Glazman <daniel.glazman@disruptive-innovations.com>
CC: "rune@opera.com" <rune@opera.com>, Jacob Rossi <Jacob.Rossi@microsoft.com>
On 3/19/14 4:35 AM, Simon Pieters wrote:
> OK. I don't mind that, personally, but I can imagine that it can affect
> performance. Does anyone object to implementing this?

I'd like to understand the proposed behavior a bit better.

It seems like in an editing context you fundamentally want to re-parse 
the stylesheet from scratch when inserting a namespace rule.  Or something.

Concretely, consider a stylesheet author who first inserts this rule:

   foo|bar { color: green; }

and then inserts this rule:

   @namespace bar url("something");

During the first step, parsing of the rule fails, since the namespace 
prefix is unknown; in at least some current browser implementations, and 
per the spec draft at http://dev.w3.org/csswg/cssom/#insert-a-css-rule 
the insertRule call will throw.  So doing these operations via CSSOM is 
probably not the right way to implement this editing behavior.

So are we only talking about inserting @namespace rules that define the 
default namespace for the sheet?  Because it seems to me that inserting 
one that defines the namespace for a prefix that wasn't defined before 
can't actually affect the OM, since there should be no rules using that 

Of course you could insert a rule that _redefines_ a prefix that was 
already defined by another @namespace rule in the sheet, but I'm not 
sure how useful it is in practice to support that....  If we _do_ have 
to support it, that requires storing the prefix when it's present with 
the selectors in the sheet, which is not required right now, as far as I 
can tell.

Received on Wednesday, 19 March 2014 13:56:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:41 UTC