RE: [CSS2.1] Clarification on section 4.1.3 and the application of escaped newlines to identifiers.

I believe we treat this in the CSS 2.1 parser in IE 8 standards mode as an error, not as gre\00000Aen. The reason is this:

escape          {unicode}|\\[^\r\n\f0-9a-f]

The hat symbol in that matching group means NOT any of those characters. So you can't have a \ followed by a \n. This means we treat \ as an unknown token, then we treat the \n as some space then we continue with a second identifier on the following line. Specifically:

_aBcDeF\gHi\\nJkL\mNoPqR\sTuVwXyZ (please treat \n as if it were an actual newline)

CSSIdentifier - _aBcDeFgHi
Unknown - \
Space - \n
CSSIdentifier - JkLmNoPqRsTuVwXyZ


-----Original Message-----
From: [] On Behalf Of Zack Weinberg
Sent: Wednesday, November 05, 2008 1:10 PM
To: W3C Emailing list for WWW Style;
Subject: Re: [CSS2.1] Clarification on section 4.1.3 and the application of escaped newlines to identifiers.

fantasai <> wrote:
> Justin Rogers wrote:
> > G Talbot has a test case that implies the following CSS identifier
> > be reconstituted by throwing out the escaped newline.
> >
> > DIV { background-color: gre\
> > en; }
> >
> > However, there is nothing in the wording of the specification that
> > implies this is true, though other browsers are clearly accepting
> > this. Below the spec  says 1) inside of a string, which we are not.
> > 2) cancels the meaning of special characters, which it is not, 3)
> > allows for inserting Unicode characters, which it again is not.
> The newline is a special character. It normally ends an identifier.
> If it is escaped, then it forms part of the identifier. In this case,
> that example should parse equivalent to
> DIV { background-color: gre\00000Aen; }

Gecko will be easy to change, but I'm not seeing other browsers do what you say they ought to do.  The attached test case uses the construct

tifier { background-color: lime; }

 -- Firefox 3 applies this rule to an element whose ID attribute is
 -- IE 7 does the same.  I don't have convenient access to 6 or 8.
 -- Opera 9.52 treats this as a parse error.


Received on Wednesday, 5 November 2008 22:33:59 UTC