W3C home > Mailing lists > Public > www-style@w3.org > January 2011

Re: [CSS21] WD 4.2: end-of-string vs. end-of-stylesheet

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 07 Jan 2011 16:44:31 -0500
Message-ID: <4D27893F.8010601@mit.edu>
To: Peter Moulder <peter.moulder@monash.edu>, www-style@w3.org
On 1/7/11 3:14 PM, Peter Moulder wrote:
> I wonder whether the correct behaviour should depend on whether there's a
> newline character between "Hello" and the end of stylesheet.

Yes, as currently specced (though this could be clearer).

> If so, then that could be a problem for external stylesheets whose representation
> doesn't allow the concept of "unterminated line".  For example, I believe
> that in DOS/Windows environments, \r\n is traditionally considered a line
> separator rather than terminator, and that files ending in \r\n are shown
> in text editors (such as notepad) as having an empty last line.

Line separators are generally line separators, yes.  That's true on Unix 
systems too.

That said, the only reason the "upon reaching the end of a line" rule is 
needed is because strings can't contain an unescaped line separator.  So 
if you get to one, that means the string is malformed.  I think phrasing 
the "end of a line" thing in terms of line separators (or better yet 
explicit characters that should cause this behavior) would make this 
clearer.

With regard to your main point, I'm not sure what the "problem" is. 
Stylesheets shouldn't be malformed.

> Certainly there are other operating systems where the standard
> representation of text files doesn't involve using an end-of-line
> character.

It doesn't matter.  What matters is that CSS strings can't contain \n, 
\r, or \f.  Since CSS style sheets are Unicode, and not whatever the OS 
"text file" format happens to be, that's sufficient to define the behavior.

> It may well be that if this example were in an external
> stylesheet with such an encoding then it should indeed be treated as
> above rather than as in the existing end-of-stylesheet example.

Why?  What's the benefit?  The idea here is to have rules that are 
simple, well-defined, and ideally do the right thing in the common 
situations when they're hit.  External stylesheets are not in fact a 
common situation where unterminated strings are hit.

> In any case, the conflict between these rules as currently stated needs
> removing one way or another.

Where is the conflict?  You parse one character at a time.  If you get 
to one of [\n\r\f] while inside a string, you use the "unexpected 
end-of-string" rule.  If you get to EOF you use the "unexpected end of 
stylesheet" rule.

> It may be useful to clarify what is meant by "reaching the end of a
> line"

Yes, agreed.  The intent is pretty clearly "reach a [\n\r\f]"

> and it may be useful to clarify whether the correct behaviour
> for the end-of-stylesheet example depends on whether there's a newline
> character between "Hello" and the end of the stylesheet.

I think that would be obvious if "end of line" were clarified.

-Boris
Received on Friday, 7 January 2011 21:45:35 GMT

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