Intent to Implement And Ship: CSSNamespaceRule

[Ramya]

Contact emails ram...@samsung.com Spec http://dev.w3.org/csswg/cssom-1/#the-cssnamespacerule-interface, http://dev.w3.org/csswg/cssom-1/#the-cssrule-interface Summary The CSSNamespaceRule interface represents an at-rule for declaring the default namespace and binding namespaces to namespace prefixes. As of now namespace rule is only used as part of parser. As per CSSOM spec mentioned, interface needs to be exposed to web, to make it mutable.

Motivation Since the feature is part of spec and Firefox and IE already support it, for compatibility it would be nice to have it in chrome. Compatibility Risk Firefox: Shipped Internet Explorer: Shipped Safari: No public signals Web developers: No signals Describe the degree of compatibility risk you believe this change pose Since major browsers like Firefox and IE already support it, compatibility risk is low. Ongoing technical constraints None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes OWP launch tracking bug https://code.google.com/p/chromium/issues/detail?id=389549 Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5631781000708096 Requesting approval to ship? Yes

[PhistucK]

Will this affect the number and index of rules in document.styleSheets[0].cssRules?

If so, can you coordinate this change with Safari (if it has not been implemented there already)? This can break mobile websites that rely on this WebKit behavior.

Note - if the number of pages that use @namespace is extremely low (perhaps search the HTTP archive, or ask a Googler to search the crawler), this can be safely shipped. If it is not low, but the combination of @namespace and cssRules[...] or rules[...] is low, this can also be safely shipped.

☆PhistucK

On Fri, Jun 19, 2015 at 6:27 AM, Ramya <ram...@samsung.com> wrote:

Contact emails ram...@samsung.com Spec http://dev.w3.org/csswg/cssom-1/#the-cssnamespacerule-interface, http://dev.w3.org/csswg/cssom-1/#the-cssrule-interface Summary The CSSNamespaceRule interface represents an at-rule for declaring the default namespace and binding namespaces to namespace prefixes. As of now namespace rule is only used as part of parser. As per CSSOM spec mentioned, interface needs to be exposed to web, to make it mutable.

Motivation Since the feature is part of spec and Firefox and IE already support it, for compatibility it would be nice to have it in chrome. Compatibility Risk Firefox: Shipped Internet Explorer: Shipped Safari: No public signals Web developers: No signals Describe the degree of compatibility risk you believe this change pose Since major browsers like Firefox and IE already support it, compatibility risk is low. Ongoing technical constraints None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes OWP launch tracking bug https://code.google.com/p/chromium/issues/detail?id=389549 Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5631781000708096 Requesting approval to ship? Yes

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Philip Jägenstedt]

The API owners met today to discuss this. CSSOM editor Simon is on parental leave, but these are the questions we would have asked:

Is there a concrete use case for exposing this, or is it "just" a matter of all supported rules in the syntax (except @charset) also having a corresponding CSS*Rule interface?

(It looks like having the CSSNamespaceRule exposed is actually required to interpret which elements selectors in other rules will match, which seems like an unfortunate API. Namespaces are weird in DOM too, but at least there it's possible to just check the namespace of a node without doing the prefix mapping manually.)

Also, is there any use in making namespaceURI and prefix mutable? I wrote an ad-hoc test, and it looks like setting has no effect in IE, and the namespaceURI and prefix attributes aren't even supported in Firefox.

Ramya, if you have any insight from attempting to implement this, that would also be valuable.

On Fri, Jun 19, 2015 at 5:27 AM, Ramya <ram...@samsung.com> wrote:

Contact emails ram...@samsung.com Spec http://dev.w3.org/csswg/cssom-1/#the-cssnamespacerule-interface, http://dev.w3.org/csswg/cssom-1/#the-cssrule-interface Summary The CSSNamespaceRule interface represents an at-rule for declaring the default namespace and binding namespaces to namespace prefixes. As of now namespace rule is only used as part of parser. As per CSSOM spec mentioned, interface needs to be exposed to web, to make it mutable.

Motivation Since the feature is part of spec and Firefox and IE already support it, for compatibility it would be nice to have it in chrome. Compatibility Risk Firefox: Shipped Internet Explorer: Shipped Safari: No public signals Web developers: No signals Describe the degree of compatibility risk you believe this change pose Since major browsers like Firefox and IE already support it, compatibility risk is low. Ongoing technical constraints None Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes or no. Yes OWP launch tracking bug https://code.google.com/p/chromium/issues/detail?id=389549 Link to entry on the Chromium Dashboard https://www.chromestatus.com/features/5631781000708096 Requesting approval to ship? Yes

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Anne van Kesteren]

On Tue, Jun 23, 2015 at 3:47 PM, Philip Jägenstedt <phi...@opera.com> wrote:
> The API owners met today to discuss this. CSSOM editor Simon is on parental

> leave, ...

https://lists.w3.org/Archives/Public/www-style/2009Oct/0181.html might
of interest.


--
https://annevankesteren.nl/

[Ramya]

While trying to implement the spec, I was having following doubts.

From this link it is specified that CSSNamespaceRule is now mutable.

http://dev.w3.org/csswg/cssom-1/#changes-from-12-july-2011-to-5-december-2013

Supporting the above

http://dev.w3.org/csswg/cssom-1/#the-cssnamespacerule-interface,

attributes namespaceURI and prefix are not readonly. So it is expected both get and set can be used on them. 

However it was specified when setting namespaceURI or prefix, if parent stylesheet has rules other than @media/@namespace it should abort with an InvalidStateError Exception.

1) Then probably [RaisesException=Setter] should be specified for namespaceURI and prefix attributes.

2) If we implement as per the above spec, if we want to change the @namespace rule attributes dynamically after some rules were added, we will never be able to change.

For ex: In the below example prefix value cannot be changed, since the StyleRule is already present in addition to namespace rule, in parent stylesheet. Is this intended behavior as per spec?

<!DOCTYPE html>

 <style>

 @namespace html-namespace url(http://www.w3.org/1999/xhtml);

 html-namespace|body {

      color: red;

 }

</style>

<script>

 var body = document.body,

 firstRule = document.styleSheets[0].cssRules[0];

 firstRule.prefix = "mywish";

 alert(firstRule.prefix);

</script>

3)Have one doubt w.r.t testcase in https://code.google.com/p/chromium/issues/detail?id=389549.

typeof CSSNamespaceRule === 'object') returns true in IE. In chrome if we implement this spec it shows as 'function'. Also even for other rules like CSSMediaRule type is shown as 'function'. 

Is this expected behavior?

[Elliott Sprehn]

On Tue, Jun 23, 2015 at 9:22 PM, Ramya <ram...@samsung.com> wrote:

While trying to implement the spec, I was having following doubts.

From this link it is specified that CSSNamespaceRule is now mutable.

http://dev.w3.org/csswg/cssom-1/#changes-from-12-july-2011-to-5-december-2013

Supporting the above

http://dev.w3.org/csswg/cssom-1/#the-cssnamespacerule-interface,

attributes namespaceURI and prefix are not readonly. So it is expected both get and set can be used on them. 

However it was specified when setting namespaceURI or prefix, if parent stylesheet has rules other than @media/@namespace it should abort with an InvalidStateError Exception.

1) Then probably [RaisesException=Setter] should be specified for namespaceURI and prefix attributes.

2) If we implement as per the above spec, if we want to change the @namespace rule attributes dynamically after some rules were added, we will never be able to change.

For ex: In the below example prefix value cannot be changed, since the StyleRule is already present in addition to namespace rule, in parent stylesheet. Is this intended behavior as per spec?

Changing this means reparsing the sheet, I'm not sure we should support that and it's of very dubious value since we don't ever plan to add more namespace oriented features.

Can we get this made read-only instead?

3)Have one doubt w.r.t testcase in https://code.google.com/p/chromium/issues/detail?id=389549.

typeof CSSNamespaceRule === 'object') returns true in IE. In chrome if we implement this spec it shows as 'function'. Also even for other rules like CSSMediaRule type is shown as 'function'. 

Is this expected behavior?

That's a bug in IE, IDL interfaces should have typeof "function".

- E 

[Anne van Kesteren]

On Tue, Jun 23, 2015 at 9:22 PM, Ramya <ram...@samsung.com> wrote:

> From this link it is specified that CSSNamespaceRule is now mutable.
> http://dev.w3.org/csswg/cssom-1/#changes-from-12-july-2011-to-5-december-2013

o_O, that seems insane.


--
https://annevankesteren.nl/

[PhistucK]

Unless I am misunderstanding, this is not so insane. Imagine you are creating a stylesheet via JavaScript, using the CSSOM APIs and want to add a namespace rule - you must set it. The restriction to only setting it before there are rules makes sense - you only need to set it before you set the rules. It is not a mechanism to change the meaning of the rules afterwards, only to set the meaning of the rules prior to setting them.

The alternative would be to create a stylesheet only using strings (newStylesheet.cssText = "@namespace ...; p { color: gray; }", which is... well, sometimes not desirable or does not look so clean).

☆PhistucK

--
https://annevankesteren.nl/

[Elliott Sprehn]

On Wed, Jun 24, 2015 at 11:34 AM, PhistucK <phis...@gmail.com> wrote:

Unless I am misunderstanding, this is not so insane. Imagine you are creating a stylesheet via JavaScript, using the CSSOM APIs and want to add a namespace rule - you must set it. The restriction to only setting it before there are rules makes sense - you only need to set it before you set the rules. It is not a mechanism to change the meaning of the rules afterwards, only to set the meaning of the rules prior to setting them.

The alternative would be to create a stylesheet only using strings (newStylesheet.cssText = "@namespace ...; p { color: gray; }", which is... well, sometimes not desirable or does not look so clean).

The sane thing is that the constructor takes the parameters and the properties are read only. I don't think we want to this mutable but throws behavior.

var rule = new CSSNamespaceRule("prefix", "url");

- E 

[PhistucK]

Wait, I do not see a constructor at all, how do you create such an instance? Looks like you can only modify it if you have a stylesheet with a @namespace and no rules and you want to append rules to it. In that case, it really makes no real sense.

☆PhistucK

[Philip Jägenstedt]

The only "API" I can see for creating a CSSNamespaceRule is styleSheet.insertRule('@namespace svg url(http://www.w3.org/2000/svg)', 0), which does work in Firefox and IE. Having CSSNamespaceRule.namespaceURI/prefix be mutable seems useless to me, even if it's only allowed when there are no other rules to invalidate. I don't think we should implement that.

To me, the real motivation to implement CSSNamespaceRule is to get the spec and implementation in sync. If it's made immutable again, I don't see why we shouldn't implement that, even though namespaces are rightfully out of fashion. A quick peek in httparchive data shows that @namespace rules do exist there out in the wild, so trying remove the support entirely doesn't seem like a worthwhile endeavor.

I've reopened https://www.w3.org/Bugs/Public/show_bug.cgi?id=22208 and think we should wait until the spec situation is sorted and then re-evaluate.

Does that sound OK?

[PhistucK]

Even so, my questions still stand, will this impact the index of rules in cssRules? That may break pages.

☆PhistucK

[Philip Jägenstedt]

It will change the indexes, and that may break stuff. However, we successfully got rid of CSSCharsetRule which also changed the indexes, and @charset is probably more common than @namespace.

[Simon Pieters]

On Wed, 24 Jun 2015 00:47:01 +0200, Philip Jägenstedt <phi...@opera.com>

wrote:

> The API owners met today to discuss this. CSSOM editor Simon is on
> parental

> leave, but these are the questions we would have asked:
>
> Is there a concrete use case for exposing this, or is it "just" a matter
> of
> all supported rules in the syntax (except @charset) also having a
> corresponding CSS*Rule interface?

Mostly the latter, in my opinion. But I also think it should be possible
to build a stylesheet with @namespace with the API (using insertRule()),
instead of having to set textContent (which would mean reparsing the full
stylesheet each time you add to it).

> (It looks like having the CSSNamespaceRule exposed is actually required
> to
> interpret which elements selectors in other rules will match, which seems
> like an unfortunate API. Namespaces are weird in DOM too, but at least
> there it's possible to just check the namespace of a node without doing
> the
> prefix mapping manually.)

The mapping is only done when parsing or inserting a rule, but yeah.

> Also, is there any use in making namespaceURI and prefix mutable? I wrote
> an ad-hoc test

> <http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3549>, and

> it
> looks like setting has no effect in IE, and the namespaceURI and prefix
> attributes aren't even supported in Firefox.

Per spec it is only mutable if there aren't any other rules in the
stylesheet that they would affect. The rationale is that if you wanted to
change the prefix, you would have to remove the @namespace rule and insert
a new one, instead of just setting .prefix.

On Wed, 24 Jun 2015 06:22:56 +0200, Ramya <ram...@samsung.com> wrote:

>
> While trying to implement the spec, I was having following doubts.
>
> From this link it is specified that CSSNamespaceRule is now mutable.
> http://dev.w3.org/csswg/cssom-1/#changes-from-12-july-2011-to-5-december-2013
>
> Supporting the above
> http://dev.w3.org/csswg/cssom-1/#the-cssnamespacerule-interface,
> attributes namespaceURI and prefix are not readonly. So it is expected
> both
> get and set can be used on them.
>
> However it was specified when setting namespaceURI or prefix, if parent
> stylesheet has rules other than @media/@namespace it should abort with an
> InvalidStateError Exception.
> 1) Then probably [RaisesException=Setter] should be specified for
> namespaceURI and prefix attributes.

([RaisesException] is not a standard extended attribute in WebIDL.)

> 2) If we implement as per the above spec, if we want to change the
> @namespace rule attributes dynamically after some rules were added, we
> will
> never be able to change.
> For ex: In the below example prefix value cannot be changed, since the
> StyleRule is already present in addition to namespace rule, in parent
> stylesheet. Is this intended behavior as per spec?
>
> <!DOCTYPE html>
> <style>
> @namespace html-namespace url(http://www.w3.org/1999/xhtml);
> html-namespace|body {
> color: red;
> }
> </style>
> <script>
> var body = document.body,
> firstRule = document.styleSheets[0].cssRules[0];
> firstRule.prefix = "mywish";
> alert(firstRule.prefix);
> </script>

Yes, this would throw per spec to avoid having to redo the namespace
mapping of all the rules.

> 3)Have one doubt w.r.t testcase in
> https://code.google.com/p/chromium/issues/detail?id=389549.
> typeof CSSNamespaceRule === 'object') returns true in IE. In chrome if we
> implement this spec it shows as 'function'. Also even for other rules
> like
> CSSMediaRule type is shown as 'function'.
> Is this expected behavior?

IIRC "function" is expected per WebIDL.

On Wed, 24 Jun 2015 07:04:21 +0200, Elliott Sprehn <esp...@chromium.org>
wrote:

> Changing this means reparsing the sheet, I'm not sure we should support
> that and it's of very dubious value since we don't ever plan to add more
> namespace oriented features.
>
> Can we get this made read-only instead?

I think you misunderstood, the spec only allows mutation of @namespace if
the stylesheet doesn't contain any rules that would be affected (so you
would never reparse the stylesheet or redo namespace mappings). But I'm
happy to change back to readonly if it's more confusing than helpful.

On Wed, 24 Jun 2015 21:55:54 +0200, Elliott Sprehn <esp...@chromium.org>
wrote:

> The sane thing is that the constructor takes the parameters and the
> properties are read only. I don't think we want to this mutable but
> throws
> behavior.
>
> var rule = new CSSNamespaceRule("prefix", "url");

CSSOM doesn't have such constructors yet, but a string-based API. A less
sucky API with constructors etc is planned but not there yet, and the
legacy API isn't going away.

HTH,
--
Simon Pieters
Opera Software

[Anne van Kesteren]

On Wed, Aug 26, 2015 at 11:47 AM, Simon Pieters <sim...@opera.com> wrote:
> Mostly the latter, in my opinion. But I also think it should be possible to
> build a stylesheet with @namespace with the API (using insertRule()),
> instead of having to set textContent (which would mean reparsing the full
> stylesheet each time you add to it).

But you don't think that using rules to expose namespaces in
stylesheets is fundamentally the wrong API? Syntax-wise it might make
some sense, but object-model-wise it seems somewhat weird. In that
they have place restrictions and usage restrictions. Seems much more
natural as a map API tied to the stylesheet. It's unclear whether such
a change can still be made though. (See the thread I referenced
earlier.)


--
https://annevankesteren.nl/

[Simon Pieters]

On Wed, 26 Aug 2015 12:03:10 +0200, Anne van Kesteren <ann...@annevk.nl>
wrote:

I don't see it being fundamentally wrong. Although a map would maybe have
been a better API, I don't think it is important that namespaces in CSSOM
have a good API when we're missing a good API for everything else. It
seems pages use CSSNamespaceRule so we should get slightly better Web
compat by supporting them.

[PhistucK]

On Wed, Aug 26, 2015 at 2:45 PM, Simon Pieters <sim...@opera.com> wrote:

I don't think it is important that namespaces in CSSOM have a good API when we're missing a good API for everything else

​:|
That is never a reason. "If everything else is rubbish, this can also be rubbish". No. Step by step.

☆PhistucK

[Philip Jägenstedt]

On Wed, Aug 26, 2015 at 11:47 AM, Simon Pieters <sim...@opera.com> wrote:

On Wed, 24 Jun 2015 07:04:21 +0200, Elliott Sprehn <esp...@chromium.org> wrote:

Changing this means reparsing the sheet, I'm not sure we should support
that and it's of very dubious value since we don't ever plan to add more
namespace oriented features.

Can we get this made read-only instead?

I think you misunderstood, the spec only allows mutation of @namespace if the stylesheet doesn't contain any rules that would be affected (so you would never reparse the stylesheet or redo namespace mappings). But I'm happy to change back to readonly if it's more confusing than helpful.

FWIW, I think it'd be an improvement to make these read-only, since that's less code and fewer tests to write. In the cases where there are no existing rules, one could still insert arbitrary namespace rules using insertRule, which takes a string argument.

Philip

[Simon Pieters]

On Wed, 26 Aug 2015 14:00:54 +0200, Philip Jägenstedt <phi...@opera.com>
wrote:

Fixed.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22208#c3

[Philip Jägenstedt]

Excellent, thank you!

Ramya, are you still interested in pursuing this? If so, LGTM to implement and ship https://drafts.csswg.org/cssom/#the-cssnamespacerule-interface

Philip 

[Ramya]

Thanks philip. Would like to implement this.

[Chris Harrelson]

LGTM2, now that it's marked as readonly.

[Rick Byers]

LGTM3

[Ramya]

While trying to upload the patch, I'm getting following presubmit error (for the line NAMESPACE_RULE in CSSRule type enum)
check-webkit-style failed
Source/core/css/CSSRule.h:54: enum members should use InterCaps with an initial captial letter. [readability/enum_casing]
Is there any way to bypass this similar to already existing enum values' style for CSSRule Type?

[Philip Jägenstedt]

Yeah, use git cl upload --bypass-hooks