grammars and parsing for regular and presentation attributes

We have already resolved (and it's also in our list of requirements for 
SVG 2) to make the spec support presentation attribute parsing case 
insensitively, e.g. fill="Red" should work just like style="fill:Red" would.

I couldn't see an issue in the tracker about allowing all CSS syntax in 
presentation attributes, e.g. fill="/**/red", although I'm sure we've 
brought it up before.  IE and Chrome both support this, while Opera and 
Firefox do not.  (Chrome also supports fill="re\64", while IE does not.) 
  I think it's a natural progression to parse these attributes entirely 
with the CSS parser.  What are people's current thoughts on this?

I am also wondering what to do about the parsing of non-presentation 
attributes.  I find it strange that for example the definition of both a 
<rect> element's x="" attribute and say the stroke-width property refer 
to the <length> type, given that we currently have non-presentation 
attribute parsing defined using EBNF grammars while properties use the 
CSS grammar syntax.  I want to remove the definitions of the data types 
like <length> in types.html and for properties at least, reference 
css3-values, but the question of what non-presentation attributes should 
refer to remains.

I don't think we want to duplicate the CSS <length> syntax (which 
includes calc() expressions now) in EBNF.  Maybe we can still utilise 
the CSS parser and invoke it with some flags that disable escapes and 
comments?

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

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

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.

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

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

Received on Saturday, 19 January 2013 01:08:29 UTC