Re: grammars and parsing for regular and presentation attributes

On Fri, Jan 18, 2013 at 7:08 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> Did you have an opinion on fill="/**/red"?

It would be good for presentation attributes to parse exactly like CSS, I think.


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

I could actually see an argument for supporting !important, though I
don't think it's very important. (Sorry.)  It's easy to see what it
would do, after all - presentation attributes normally live in the
author style sheet, and putting an !important at the end would just
move them into the author-!important origin.


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

Agreed.  I don't see why non-presentation attributes that nevertheless
use similar values shouldn't get the full suite of CSS value
functions.  calc() is only one example.  attr() and var() also make
sense.  (toggle() doesn't, but only because attributes which aren't
reflected in stylesheets don't have a concept of inherited value.
Nevertheless, it could still be used, with a minimal patch to specify
how it works.)


>>> 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?

If we do *any* mixing with CSS, it would probably be valuable to
rewrite all of them fully in CSS grammar.


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

Converted fully to CSS grammar, that would just be "<length> [ ,? <length>]*".


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

The CSS parser does this same normalization, so it's not that critical
to do anything on the SVG side.


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

I don't understand what you're referring to.


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

Oh gosh, we definitely do *not* want to invoke the CSS quirks for
parsing SVG.  SVG already has a flag in the CSS parser, and I can add
more if necessary.  For example, we could invoke the unitless length
quirk on SVG properties without pulling in the hashless color quirk.

(Note that the CSS quirks that used to live in the WHATWG spec have
been removed, since they're now in the Syntax spec.)

~TJ

Received on Saturday, 19 January 2013 17:42:46 UTC