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

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:
>>>   For the sentence:
>>>     "First, inside a string, a backslash followed by a newline is
>>>      ignored (i.e., the string is deemed not to contain either the
>>>      backslash or the newline)."
>>>   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."
>>
>> it should be "demeed to contain neither backslash nor newline". You
>> have 'whether' which i think is a typo for 'either'.
>
> It was meant to be correct. But the "or" should probably be "nor":
>      "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
> http://www.pcreview.co.uk/forums/no-we-do-not-know-whether-cost-nor-much-after-release-t1698715.html
>
> But here is a minimum change (for that part of the sentence) - simply
> delete the confusing word "either" and replace "or" with "nor":
>      "deemed not to contain the backslash nor the newline."
> Best?


(Note: white-space is important is what I have below)


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


   | First, inside a string, a backslash followed by a newline
   | is ignored (i.e., the string is deemed not to contain
   | either the backslash or the newline).


This apply if the escape is in a string 4.3.7 [1].


   | Strings can either be written with double quotes or with
   | single quotes.


So in the example in the spec,

     a[title="a not s\
o very long title"] { background:green }

becomes.

a[title="a not so very long title"] { background:green }


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.


>>> 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. You 
can not have "backslash followed by newline" neither since it is the 
backslash that has causes a newline to appear. 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).


The last part could be this.


   > the newline (i.e., the string is deemed not to contain
   > the backslash nor the newline).


After this part the spec continues in saying in 4.1.3.


   | Outside a string, a backslash followed by a newline
   | stands for itself (i.e., a DELIM followed by a newline).



Currently all browsers drop this,

      \ div { background: green }


but only Firefox 3.6~4b parses both of theses.

      \
div { background: green }

      \
  div { background: green }


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 }

      \ div { background: green }


The first one '\d' has a special meaning so Firefox 3.6~4b has a bug. 
I'm not sure what should happen with the later that has white-space.

Some other examples and how browser handle them (either parsing them or 
dropping them).


     \p { background: green } /* parsed */

     \ p { background: green } /* dropped */



     \div { background: green } /* dropped */

     \ div { background: green } /* dropped */



     d\i\v { bac\k\g\r\o\u\nd: \g\ree\n } /* parsed */

     \0064\0069\0076 { 
\0062\0061\0063\006B\0067\0072\006F\0075\006E\0064: 
\0067\0072\0065\0065\006E } /* parsed */



More example which only Firefox 3.6~4b parses.

      \
p { background: green } /* FF 3.6~4b parses */

      \
  p { background: green } /* FF 3.6~4b parses */

      \
div { background: green } /* FF 3.6~4b parses */

      \
  div { background: green } /* FF 3.6~4b parses */

      div\
{ background: green } /* FF 3.6~4b parses */

      div\
  { background: green } /* FF 3.6~4b parses */


With '*', we get something different.

\* { background: green } /* WebKit parses */

\ * { background: green } /* dropped */

\
* { background: green } /* dropped */

\
  * { background: green } /* FF 3.6~4b parses */



More example which only Firefox 3.6~4b parses.

\0064\
\0069\0076 { \0062\
\0061\0063\006B\0067\0072\006F\0075\006E\0064: \0067\
\0072\0065\0065\006E }


\
\0064\
\
\0069\0076 { \0062\
\
\0061\0063\006B\0067\0072\006F\0075\006E\0064: \0067\
\
\0072\0065\0065\006E }
\


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 */

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

     \0062\006F\0064\0079\
  div { background: lime } /* FF 3.6~4b parses */



The way all this should world with escape, newlines and white-space 
needs to bee looked at, especially if authors who use meaningful ID or 
class names should be able to easy select elements like this.

  <div class="α">

    <p class="ω">This paragraph should have a green background.</p>

   </div>


Here are four test cases.


http://css-class.com/test/css21testsuite/escapes-060.xht

http://css-class.com/test/css21testsuite/escapes-061.xht

http://css-class.com/test/css21testsuite/escapes-062.xht

http://css-class.com/test/css21testsuite/escapes-064.xht


FF 3.6~4b parses 'escapes-061', 'escapes-062' and 'escapes-064'.

All other browsers parses 'escapes-062' and 'escapes-064'.



>>>   For the sentence:
>>>     "Second, it cancels the meaning of special CSS characters."
>>>   Replace "it cancels" with "using plain backslash escapes to cancel":
>>>     "Second, using plain backslash escapes to cancel the meaning of
>>> special
>>>      CSS characters."


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.


[1] http://www.w3.org/TR/CSS21/syndata.html#strings


-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo

Received on Monday, 4 April 2011 16:21:58 UTC