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

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 UTC