Re: [CSS21] Escaping characters (comment, editorial)

Alan Gresley, Tue, 05 Apr 2011 02:21:16 +1000:
> On 4/04/2011 4:18 AM, Leif Halvard Silli wrote:
>> timeless, Sun, 3 Apr 2011 15:51:22 +0300:
>>> On Sun, Feb 20, 2011 at 7:14 PM, Leif Halvard Silli wrote:

>>>>   Insert the wording "backslash newline escape" etc:
>>>>     "First, inside a string, a plain backslash newline escape (backslash
>>>>      followed by newline) cancels the meaning of the newline so that
>>>>      the string is deemed to not contain whether backslash or newline."
  [variant b]
>>      "is deemed to not contain whether backslash nor newline."
>> It is meant to match sentences such as this one: "we do not know
>> whether it will cost nor how much", see
  [variant c]
>>      "deemed not to contain the backslash nor the newline."

> I don't think that is what the spec is saying in 4.1.3.

May be because you didn't got the fine points of was it said? See below.

[ snip ]

> If white-space was added, then this,
> 
>     a[title="a not s\
>  o very long title"] {background:green}
> becomes.
>     a[title="a not s o very long title"] {background:green}
> 
> I see this above as different wording.

Note the words "so that": "cancels the meaning of the newline _so that_ 
the string is deemed to not contain whether backslash or newline".

>>>> First, inside a string, a plain backslash newline escape
>>>> (backslash followed by newline) cancels the meaning of the
>>>> newline so that  the string is deemed to not contain whether
>>>> backslash or newline."
> 
> An escape (backslash) does not cancel the meaning of a newline since 
> an escape at the end of the current line causes a newline to appear.

Again, note that "so that" begins a phrase which describes what 
"cancels" means. The "special meaning" that newline has inside a string 
is that it is illegal. But with \ before it becomes legal as well as 
ignored.
 
> You can not have "backslash followed by newline" neither since it is 
> the backslash that has causes a newline to appear.

Inside "a string", no newline appears. It doesn't disappears either. It 
is simply "deemed" to not be there.

> I believe the 
> below word wording is more to the point.
> 
>   > First, inside a string, an escape (backslash) followed
>   > by a newline cancels the meaning of both the escape and
>   > the newline (i.e., the string is deemed not to contain
>   > either the backslash or the newline).

An escape cannot cancel the meaning of itself. ;-) The special escape 
character meaning of \ is not cancelled  ...

  [ snip ]

> but only Firefox 3.6~4b parses both of theses.
>      \
> div { background: green }
  [ snip ]
> If a backslash followed by a newline stands for itself outside a 
> string, then the above statements which Firefox 3.6~4b parses would 
> appear like this I think.
> 
>      \div { background: green }

No. Outside a string, the newline becomes a space:

       \ div{}

The Firefox bug is that it does not discern between inside and outside 
a string. There ought to be a test case to catch that.
 
> With '*', we get something different.
> 
> \* { background: green } /* WebKit parses */

Yes. I have asked for a test case for that thing.

http://lists.w3.org/Archives/Public/public-css-testsuite/2011Feb/0089.html

> For any other browser, the remainder of the style sheet is thrown out 
> unless it something like 'p' is pulled in behind like what happen 
> with '\p { background: green }'.
> 
> The nesting of identifiers is important it seems.
>     body \0064\0069\0076 { background: lime } /* parsed */
>     \0062\006F\0064\0079 div { background: lime } /* dropped */

There needs to be one more space before the div. Read the spec - I'll 
just quote one bit:
 
]]  Note that this means that a "real" space after the escape sequence 
must be doubled. [[ 

Thus:
     \0062\006F\0064\0079  div { background: lime } /* parsed */

In theory, this should have worked, though, but doesn't:
 \000062\00006F\000064\000079 div { background: lime } /*dropped*/
Above there are 6 digits in each escape, and thus the double space 
ought not to have been necessary. But, alas, it seems to be needed.

Some place you also had these example:

>     \p { background: green } /* parsed */
>     \ p { background: green } /* dropped */
> 
>     \div { background: green } /* dropped */
>     \ div { background: green } /* dropped */

The difference between \p and \div is related to the fact that the 
Unicode escapes uses the characters in the 0-9 and A-F range. Thus, in 
case of \div, then it looks to the user agent as an incorrect/illegal 
escape sequence. I don't know if the spec talks about that problem, but 
at least it says this:

 ]] If a character in the range [0-9a-fA-F] follows the hexadecimal 
number, the end of the number needs to be made clear. [[k

You can also try this document, to check how <f> and <g> are treated 
differently:

<!DOCTYPE html><style>\f,\g{background: lime;}</style><f 
class=f>f</f><g class=g>g</g>


 [...]

> I would like to answer the rest of the email but I have already spent 
> about 10 hours on this one and testing. I will reply more in part 
> later.

Bear in mind that this letter is meant to be an *editorial* comment.
-- 
leif halvard silli

Received on Wednesday, 6 April 2011 12:59:02 UTC