- From: Peter Moulder <peter.moulder@monash.edu>
- Date: Sat, 23 Apr 2011 12:34:47 +1000
- To: www-style@w3.org
On Sat, Apr 23, 2011 at 02:07:41AM +0200, Bjoern Hoehrmann wrote: > * fantasai wrote: > >I believe this testcase > > http://test.csswg.org/suites/css2.1/20110323/html4/uri-015.htm > > > > background: red U\r\4c ("support/swatch-green.png"); > > > >is wrong according to the core grammar. But I'm not 100% sure... > >Also, we have three passes on the testcase. Do we want the testcase > >or the grammar to be right? (I think the grammar should be right > >in this case, making this pass probably does more harm than good.) Some relevant information: - The core grammar differs from the (non-normative) CSS 2.1 grammar on this point. - Most user agents I tested (probably stable/older versions) follow the core grammar here, and hence fail that test case. An exception is Gecko, but that's only because Gecko doesn't have correct tokenization behaviour for URI generally: Gecko still uses a FUNCTION token to handle url(...), but a result of this is that it does the wrong thing for url(/*blah*/x.png), treating /*blah*/ as a comment rather than part of the URI. Whereas for rgb(), I think all the UAs I tested did allow escapes. > The CSSWG resolved not to make these changes. I don't know what "these changes" are: presumably there should be some action, whether it's changing the testcase and the CSS 2.1 grammar, or changing the core grammar. The prose describing rgb() syntax is misleading, too: it says # The format of an RGB value in the functional notation is 'rgb(' # followed by a comma-separated list of three numerical values # (either three integer values or three percentage values) followed # by ')'. [...] White space characters are allowed around the # numerical values. This wording suggests that R\47 b(...) is not a valid RGB value. Explicitly mentioning the possibility of white space might introduce doubt as to whether comments can occur. I'd suggest mentioning FUNCTION token somehow, and I'd suggest inserting "(and/or comments)" when mentioning white space. (I'd be inclined to remove the word "characters".) (Regarding whether to mention comments: I grant that syndata.html already mentions that comments can occur outside of any other tokens -- which is why I parenthesized that note. However, just because the grammar allows comments everywhere doesn't mean that they never change the meaning, e.g. in the case of @charset. The paragraph is currently written in terms of characters rather than tokens, which is part of why it seems appropriate to mention comments, even if parenthetically. If the paragraph were instead changed to be written in a clearly non-normative way and referencing a normal BNF grammar rule with FUNCTION and S tokens etc. then I wouldn't mention comments.) pjrm.
Received on Saturday, 23 April 2011 02:35:14 UTC