W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: Proposed revision of CSS2.1 description of backslash escapes

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 02 Sep 2010 18:38:18 -0700
Message-ID: <4C80518A.2070109@inkedblade.net>
To: Bert Bos <bert@w3.org>
CC: Zack Weinberg <zweinberg@mozilla.com>, W3C Emailing list for WWW Style <www-style@w3.org>, "L. David Baron" <dbaron@dbaron.org>
On 08/04/2010 08:47 AM, Bert Bos wrote:
> On Thursday 15 July 2010 21:49:38 Zack Weinberg wrote:
>
>> I'd be okay with a much smaller patch.  I didn't like my previous
>> attempts to just insert the new normative requirements without also
>> revising the whole section, but here's another go at it:
>>
>>    * Replace "indicates three types of character escapes" with "may
>>      indicate one of three types of character escape.  Inside a CSS
>>      comment, a backslash has no special meaning, and if a backslash
>>      is immediately followed by the end of the style sheet, it also has
>>      no special meaning."
>>
>>    * Append "Outside a string, a backslash followed by a newline has
>>      no special meaning." to the paragraph beginning "First, inside a
>>      string".
>>
>>    * Delete "Except within CSS comments" from the paragraph beginning
>>      "Second, it cancels".
>>
>>    * Delete ", where allowed," from the note at the bottom of the
>>      section.
>
> So far so good, but...
>
>>    * Append this text to the first paragraph of the note at the bottom
>>      of the section: "When a backslash has 'no special meaning', it is
>>      tokenized like any other punctuation character without special
>>      meaning: as part of a comment, part of a string, or as a DELIM,
>>      based on the context."
>
> ... this appears to put a normative statement (viz., the definition
> of "no special meaning") inside a note.
>
> So I wonder if the "no special meaning" phrase can be avoided. How about
> this (which is otherwise the same as your list above):
>
>     * Replace "indicates three types of character escapes" with "may
>       indicate one of three types of character escape. Inside a CSS
>       comment, a backslash stands for itself, and if a backslash
>       is immediately followed by the end of the style sheet, it also
>       stands for itself (i.e., a DELIM token)."
>
>     * Append "Outside a string, a backslash followed by a newline stands
>       for itself (i.e., a DELIM followed by a newline)." to the paragraph
>       beginning "First, inside a string".
>
>     * Delete "Except within CSS comments" from the paragraph beginning
>       "Second, it cancels".
>
>     * Delete ", where allowed," from the note at the bottom of the
>       section.

Zack, earlier in the thread you wrote:

> I *believe* that the only normative changes are to clarify the behavior
> of \-newline not within a string, and \-EOF in any context.  However, I
> may have made errors.  Please let me know if you find any.

However, as I was checking Bert's edits I noticed that these changes
introduce another normative change: specifically, they disallow unicode
escapes within a comment.

I think this is a harmful change for two reasons:
   - First, it makes it impossible for a comment to represent */
   - More importantly, it makes it impossible to reliably translate a
     style sheet from a full-fledged UNICODE encoding to any other
     encoding.

I think this issue should be reopened and the proposal adjusted to not
make this change.

(Also, you want s/may indicate/can indicate/ since this is not an RFC2119
"may", i.e. the behavior is not optional, it is only conditional.)

~fantasai
Received on Friday, 3 September 2010 17:57:51 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT