- From: L. David Baron <dbaron@dbaron.org>
- Date: Wed, 15 Oct 2003 15:39:36 -0700
- To: Tex Texin <tex@i18nguy.com>
- Cc: www-style@w3.org, W3c I18n Group <w3c-i18n-ig@w3.org>
On Wednesday 2003-10-15 17:39 -0400, Tex Texin wrote: > http://www.w3.org/TR/CSS21/syndata.html : > > The range should be [0-9a-fA-F], since characters g-zG-Z are clearly > beyond the hexadecimal number. Agreed. > 2) Section 4.4 on CSS document representation > Mention should be made of the Unicode BOM and its relationship to the encoding > of the file. Porting the additional text in [2] back to CSS 2.1 could be a start, although it might be worth adding some additional text beyond that. (For example, a BOM could indicate that a stylesheet is UTF-16, as having priority immediately lower than @charset.) > 5) The section 4.3.7 on strings introduces \A for newline and points to an > example, so I assume there isn't a section describing other backslash codes > (e.g. \t etc.). However, the section doesn't define what the user should do if > they actually want a linefeed. > > Is \0A (not \A) supposed to generate a linefeed or a newline? In other words, > is that string "\A" a special string, or is the character code U+000A mapped to > linefeed in css? The parenthetical remark seems to indicate that CSS redefines > the Unicode character. > > (Which seems like a very odd and dangerous thing to do.) XML normalizes CR, LF, and CRLF to LF [1], so it seems reasonable to treat LF as the new line character within the CSS processing model. It only matters when 'white-space' is 'pre', though. Do you have a better alternative in mind? -David [1] http://www.w3.org/TR/2000/REC-xml-20001006#sec-line-ends [2] http://www.w3.org/TR/2003/WD-css3-syntax-20030813/#css-style -- L. David Baron <URL: http://dbaron.org/ >
Received on Wednesday, 15 October 2003 18:39:38 UTC