Re: [cssom] CSSNamespaceRule

On 11/03/2014 11:15, Daniel Glazman wrote:
> http://dev.w3.org/csswg/cssom  says [1] about CSSNamespaceRule that
> setting namespaceURI or prefix attribute should throw an exception if
> the parent stylesheet contains anything other than @charset, @import
> and @namespace rules. I fail understanding why. If the namespace rule
> is already in the OM, then it's valid wrt CSS syntax and position in
> the sheet. I think this is wrong. As an editor vendor, the setters on
> these two attributes seem to me, as is, totally useless: a namespace
> rule in a complete stylesheet already containing style rules is, because
> of the above, not modifyable; an editor would have no other choice but
> to delete it and insert a new one to provide the user with namespaceURI
> or prefix editing.
>
> I recommend just throwing away the two "On setting..." lists in section
> 6.4.10, it seems like an erronenous copy and paste from [2] item 7.
>
>
> On another note, I don't understand better item 7 in [2]... It seems
> to me totally wrong and a blocker to editors.
>
> [1] http://dev.w3.org/csswg/cssom/#the-cssnamespacerule-interface
> [2] http://dev.w3.org/csswg/cssom/#insert-a-css-rule

My understanding is that the rationale for [1] and [2] is the same: make 
sure that the mapping of namespace prefixes to namespace URLs does not 
change while any rule based on it exists.

In Selectors (or anything else based on namespace declarations), 
implementation may want to eagerly resolve prefixes into URLs when 
parsing so that they don’t have to do it when matching.

Any change to @namespace rules also changes the meaning of other rules. 
Implementations would have to go and re-parse (or at least re-compile) 
Selectors in the rest of the stylesheet.

Maybe the flexibility is worth the implementation cost. On the other 
hand I don’t know if Namespaces is something people are interested in 
spending effort improving, rather than a legacy feature we’re stuck 
supporting for compatibility with deployed content.

-- 
Simon Sapin

Received on Tuesday, 11 March 2014 15:13:06 UTC