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

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