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

Re: [css3-syntax] Reviving the spec, starting with the parser

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 12 Apr 2012 21:47:13 -0700
Message-ID: <CAAWBYDCiTiQ8aVr9Boi_=hNhHkfF2gqGNo3o1K9a6hLHb=jbbw@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>
On Thu, Apr 12, 2012 at 8:39 PM, Dirk Schulze <dschulze@adobe.com> wrote:
> I just want to make sure that specifying the parsing doesn't make current CSS parsers inflexible.

It's exactly as flexible as a grammar-based parser.  (And easier to
reason about, imo.)

> For instance the CSS parser in WebKit can easily be modified to support the SVG parsing rules on transform lists for CSS Transforms [1] on SVG presentation attributes. This includes whitespaces between function names and the first opening brace, comma or whitspace separation of arguments or functions and so on. I wouldn't be happy to write the parser for transform functions twice. (Nearly) all browsers engines support scientific notations for numbers on SVG presentation attributes and like I wrote before: I bet no one implemented the CSS parser a second time just for SVG presentation attributes!

I didn't know about the whitespace-in-function-token bit.  That's an
easy change to make.

As I said earlier, I'm going to add the ability to parse
scientific-notation numbers.

Separation of function arguments is a matter for the value's own
grammar to cover.  The grammar of individual properties and values is
not the concern of the Syntax module.

> The last part is the quirks mode. I am sure that no one wants to maintain a second parser for quirks mode. Even if just some properties differ. Therefore css3-syntax should be aware of all this.

I already stated that I'll be integrating the necessary quirks.  It
looks like it's just two - the hashless hex color and the unitless
length.  I'll need to do some extra work, though - I think the
hashless hex color algorithm is incorrect (it wouldn't convert
"a00000" into a hash token).

Received on Friday, 13 April 2012 04:48:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:14 UTC