- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 18 Feb 2013 20:12:44 -0800
- To: Zack Weinberg <zackw@panix.com>
- Cc: www-style list <www-style@w3.org>
On Mon, Feb 18, 2013 at 7:15 PM, Zack Weinberg <zackw@panix.com> wrote: > 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). While the SVGWG hasn't 100% decided on it yet, we're leaning strongly toward "just parse as CSS" for presentational attributes, so comments would be allowed. ~TJ
Received on Tuesday, 19 February 2013 04:13:31 UTC