Re: grammars and parsing for regular and presentation attributes

Cameron McCormack:
>> Should <rect x=" 10"> be valid by the way?

Dirk Schulze:
> First, webkit and IIRC Firefox as well use their CSS Parser for
> presentation attributes anyway. That is why you see more restrictions
> on the "x" attribute, then on "text-size". First is an SVG attribute,
> the second is a presentation attribute. However, CSS syntax can be a
> lot more restrictive then SVG syntax too, as seen on the grammar for
> polygon, paths and transforms. For paths and polygon we did not even
> clarify if we want to support unit types. I would be really careful
> about a generalization across all attributes.

Yes, I'm not advocating parsing non-presentation attributes exactly like 
properties.

Did you have an opinion on fill="/**/red"?

>> And have we decided to allow calc() expressions in lengths in
>> non-presentation attributes, like <rect x="calc(10px + 20%)"> (even
>> not considering the general plan to convert attributes like this to
>> properties)?
>
> I am not sure if we decided to support calc() as function yet. We
> definitely don't support "!important" for example. Can we concentrate
> on moving attributes to presentation attributes first?

I don't think it makes sense to support !important even if we wanted to 
parse the value of x="" as a CSS <length> (since !important is part of a 
declaration, not the property value).

Promoting attributes to properties wouldn't necessarily mean that we 
would need to change the parsing of the now-presentation attributes to 
be parsed just like a property value.  I think it would strongly suggest 
that calc() should be supported, though.

>> I was wondering if we could eliminate the EBNF in the spec entirely
>> and rely only on CSS grammar syntax, but that's probably not
>> feasible, at least for complicated attributes like <path d="">.  I
>> think what we need is a defined way for EBNF grammars to refer to
>> CSS grammar non-terminals.  (We could visually differentiate EBNF
>> and CSS grammar non-terminals to try to avoid confusion in how
>> they're parsed.)
>
> Wouldn't it end up in exactly the separation between CSS and SVG
> syntax? Note that I needed to do it for the "transform" attributes
> and co. on CSS Transforms already.

It's not clear to me from the CSS Transforms spec exactly how a 
transform="" attribute should be parsed.  From this section 
http://dev.w3.org/csswg/css3-transforms/#svg-syntax it sounds like it 
parses just like the property, but with a couple of changes (allowing 
unitless <angle>, for example).  If it is indeed parsed just like the 
property, i.e.

   none | <transform-function> [ <transform-function> ]*

then I think it means CSS comments in the middle of the attribute are 
acceptable.  Is that right?

>> Let's take <text x=""> as an example.  That's a
>> white-space-or-comma-separated list of <length> values.  If we use
>> EBNF for the attribute as a whole, we could write:
>>
>> list-of-lengths ::= <length> | <length> comma-wsp list-of-lengths
>> comma-wsp ::= (wsp+ ","? wsp*) | ("," wsp*) wsp ::= (#x20 | #x9 |
>> #xD | #xA)
>>
>> So angle-bracketed non-terminals reference CSS grammar symbols, and
>> bare identifiers refer to EBNF non-terminals rather than being
>> literals as in CSS grammar syntax.
>
> Using bracket value types seems reasonable to minify the syntax.

I think if anything it should use the "?" from EBNF, so that we don't 
have to have a third grammar syntax.

>> (We should also consider aligning our set of white space characters
>> with those in CSS, where CR isn't supported, remembering that XML
>> will normalize CRs to LFs when parsing.)
>
> What kind of document will a standalone SVG document be? We talk
> about removing XML bindings, but don't clarify this part. If it is
> not XML anymore, what will it be? What kind of parser is supposed to
> parse an SVG document?

This doesn't seem relevant to my comment about white space characters. 
I'm not sure exactly which discussions you're referring to, but in the 
spec we should be defining the behaviour of the document in terms of the 
DOM (or the Infoset) rather than XML itself.  Of course we will be 
keeping the XML syntax for SVG, as people do use it. :)

>> There might be some trickiness with white space parsing within the
>> <length>, as I think CSS parsing will normally consume any
>> trailing white space, which we might not want to do here.
>>
>> What do people think (and Tab in particular, since he's the
>> css3-syntax editor)?
>>
>
> Note that I am open for discussing using CSS Syntax on presentation
> attributes, but in a less restrictive mode. Maybe the "quirks mode"
> started by WHAT WG?

I think we don't want to invoke the quriks mode flag of css3-syntax, as 
that also implies for example hashless colour values, which would make 
fill="ff0000" parse.  The remainder of the quirks in 
http://quirks.spec.whatwg.org/ don't seem relevant to SVG.

Received on Saturday, 19 January 2013 03:09:20 UTC