Re: [cssom] Rationale for including (or not) CSSCharsetRule

On Tue, 28 May 2013 16:03:11 +0200, Anne van Kesteren <annevk@annevk.nl>  
wrote:

> On Tue, May 28, 2013 at 2:21 PM, Simon Pieters <simonp@opera.com> wrote:
>> Could both of you please elaborate on the rationale regarding
>> CSSCharsetRule?
>
> Well, @charset is a syntax construct similar to a curly brace or a
> space (i.e. unlike the other at-rules). It does not require
> representation as an object.

On Tue, 28 May 2013 16:17:39 +0200, Glenn Adams <glenn@skynav.com> wrote:

> I did so after reviewing current implementations, and finding a global
> binding for CSSCharsetRule as well as finding members for
> CSSRule.CHARSET_RULE. There seemed to be no reason to gratuitously break
> compatibility with DOM-2 Style by removing this.

On Tue, 28 May 2013 16:24:13 +0200, Simon Sapin <simon.sapin@exyr.org>  
wrote:

> @charset is not a rule comparable to @import, it’s closer to a BOM. It’s  
> not something defined in terms of component values, tokens, or even  
> characters, it’s an exact byte pattern that is matched before  
> tokenization even starts.
>
> What would it mean to add or change a CSSCharsetRule on a parsed  
> stylesheet?

On Tue, 28 May 2013 16:31:07 +0200, Glenn Adams <glenn@skynav.com> wrote:

> I agree it doesn't have that much utility. One could construct a
> CSSStyleSheet from scratch and then use CSSCharsetRule for serializing
> APIs. But removing/replacing a rule on an in-memory style sheet wouldn't
> cause an encoding change to occur.
>
> Again, my only reason for suggesting it be retained is for backwards
> compatibility (for old JS code that happens to reference it... don't ask  
> my
> to tell you which old JS code is using it though).

Thanks for the responses.

Comparing with other things, there's precedent for both sides:

BOM is not represented in the output anywhere
XML declaration is not represented in the DOM
HTML <meta charset> is represented in the DOM

Compat-wise, it's hard to tell if anything would break if we remove  
@charset from the CSSOM representation. It could break subtle things like  
the following:

CSS:
@charset "utf-8";
#foo { margin:0 }

JS:
var foo_rule = document.styleSheets[0].cssRules[1];

Personally, I agree with Anne and Simon that it would be cleaner to not  
have it represented. The serializer use case seems weak since a serializer  
can just always emit utf-8 (and then it could also emit the declaration  
without worrying about ending up with two @charset rules).

However, having the rule represented isn't really actively harmful, either.

What I'd like to know at this point is if any browser vendor is willing to  
experiment with dropping CSSCharsetRule and seeing if there is a compat  
impact.

-- 
Simon Pieters
Opera Software

Received on Wednesday, 29 May 2013 09:11:51 UTC