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

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).

~TJ

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