- From: Zack Weinberg <zackw@panix.com>
- Date: Mon, 18 Feb 2013 22:15:47 -0500
- To: www-style@w3.org
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