Re: [css3-syntax] SVG presentation attributes (Re: Critique of Feb 15 draft

On 2013-02-18 4:41 AM, Peter Moulder wrote:
>>> <circle cx="10" cy="10" r="5" fill="#E0B0FF /* international
>>> danger mauve */"/> <circle cx="20" cy="10" r="5"
>>> style="fill:#E0B0FF /* international danger mauve */"/>
>
> I'd suggest changing the test case to put the comment before the
> #E0B0FF: two of the SVG renderers I tested are simply ignoring
> anything after the #E0B0FF for the presentation attribute, whether
> it's a comment or not, but having the comment before the <color>
> shows that they don't strip CSS comments.

I've made this change in
http://www.owlfolio.org/scratchpad/danger-mauve.svg . (Actually, there
are now three circles, so it now tests having the comment in both
possible places relative to the color token.  If I understand the spec
requirements correctly, the circles should be mauve, black, and black
going left to right.  If you don't see three circles, do a force reload;
my site has perhaps overly aggressive cache settings for SVG files.)
Thanks for the tip.

...
> A consequence of these differences is that the CSS tokenizer can't be
> used for reading SVG presentation attributes.  (The tokenization is
> much simpler, and one would typically implement as parsing the
> character stream directly rather than going through a tokenizer
> abstraction.)

So what you're saying is that the SVG spec doesn't explicitly say "CSS
comments may not appear in presentation attribute values" because it's
actually defining its own from-scratch syntax for presentation
attributes that happens to be almost but not quite exactly the same as
CSS value syntax, and which doesn't *have* comments.  That makes a good
deal more sense than what I thought was going on (which was that it was
trying to define presentation attribute syntax by reference to CSS
without ever actually saying so).

> So the question of what flags the tokenizer in css3-syntax needs for
>  presentation attributes is actually moot.
...
> whereas for web browsers, it's SVG that's the afterthought, and
> presentation attributes are often implemented in terms of CSS
> parsing, and accordingly misbehave in the rare cases where uppercase
> units or a comment or backslash is encountered.

Much as I dislike having the "this is an SVG presentational attribute" 
mode bit in Gecko's CSS scanner and parser, a separate parser for SVG 
presentational attributes would almost-duplicate enough code that I 
think it would be worse.  As such, if SVG wants to keep its value syntax 
comment-free, I think the necessary mode bit *should* be described in 
css3-syntax (and in Values and Units, for the case-sensitive DIMENSIONs 
and "no unit at all == px" rules).

zw

Received on Tuesday, 19 February 2013 03:16:16 UTC