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

[CSS21] url() and rgb() parsing

From: Peter Moulder <peter.moulder@monash.edu>
Date: Sat, 23 Apr 2011 12:34:47 +1000
To: www-style@w3.org
Message-id: <20110423023447.GA24934@bowman.infotech.monash.edu.au>
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.)

Received on Saturday, 23 April 2011 02:35:14 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC