Re: [cssom] CSSNamespaceRule

On 3/19/14 10:25 AM, Simon Pieters wrote:
> I'm not Daniel but I think the scenario is more like: you start out with
> a stylesheet that has a bunch of rules and no @namespace and no rules
> using namespace prefixes. Then you want to insert @namespace svg "...";
> at the top and svg|foo { ... } somewhere else.

OK.  So in this scenario you insert the @namespace rule first and then 
insert the rule using the prefix.  That all seems fine to me.

> You are right that in that scenario it would not actually affect the
> existing rules, but if we allow insertion and changing of @namespace
> rules, I think it seems sane to have the other rules change.

It does, but you start running into various insane edge cases.  Say I 
have a stylesheet with |@namespace svg "..."| and a rule containing 
"svg|foo" in the selector.  Then I remove the namespace rule.  What 
should happen?

And as a side note, what then happens when such a thing is serialized? 
After all, that's what CSS editors really care about in the end: 
producing a serialization that will then later be parsed by a CSS renderer.

> No, also ones that define prefixes, and not only inserting but also
> changing existing ones.

OK.  That adds a lot more complexity, which I'm a bit loath to do unless 
we have concrete use cases.  In particular, without concrete use cases 
it's hard to define the behavior in various edge cases here.

> More interesting is maybe editing of an existing @namespace rule, e.g.
> if there was a typo in the value.

That's a good concrete use case, assuming you mean a typo in the 
namespace URI, yes.  I agree that for an editor it's desirable to 
support this.

> What if you want to change the prefix? Changing it would render rules
> using the old prefix invalid. Should they be dropped? Or magically also
> change their prefixes? Or be kept in in an invalid state? Or should the
> setter throw?
>
> What should happen when an @namespace rule is removed?

Yep.  I'll just note I hadn't read this far when I asked the same 
question above.  ;)

>> 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.
>
> You have to store the unparsed selector already since it's exposed in
> CSSOM

Where is it exposed?  Gecko does not store unparsed selectors; we simply 
serialize the parsed representation if requested (e.g. if someone gets 
.cssText on a selector).

-Boris

Received on Wednesday, 19 March 2014 15:03:28 UTC