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

On Mon, Feb 18, 2013 at 02:47:44AM +0100, Simon Sapin wrote:

> Le 17/02/2013 19:08, Zack Weinberg a écrit :

> >A more significant SVG wart, which *does* require a tokenizer flag,
> >is: in Gecko, IE, and Opera (but not Webkit), CSS comments are
> >disabled when parsing an SVG mapped attribute.  For instance:
> >
> >     <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.

> Which is the desired behavior? Which is specified? (I can’t find in
> the SVG spec if the syntax of the fill attribute is supposed to be
> CSS.)

SVG Full offers both CSS-based styling and presentation attributes,
and describes presentation attributes as meeting the following two usage scenarios:

  # 1. SVG content used as an exchange format (style sheet language–independent):
  # ...
  # Since support for a particular style sheet language is not guaranteed
  # across all implementations, it is a requirement that SVG content can be
  # fully specified without the use of a style sheet language.

(In particular, CSS style sheets aren't part of SVG Tiny.)

  # 2. SVG content generated as the output from XSLT:
  # ...
  # It is a requirement that fully specified SVG content can be generated from
  # XSLT.

The SVG Tiny 1.2 spec adds that presentation attributes are also suitable for
documents used as *input* to XSLT for modification of styling:

  # _Restyling_.  SVG content that uses the presentation attributes is highly
  # compatible with downstream processing using XSLT [...].

As far as XSLT is concerned, backslash or /*...*/ in attribute values have no
special meaning, and are simply part of the value just like a-z.

Another difference from CSS tokenization is that in SVG presentation
attributes, units must be in lower case, i.e. 9PT is an illegal value rather
than being equivalent to 9pt as in CSS.

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 the question of what flags the tokenizer in css3-syntax needs for
presentation attributes is actually moot.

I've cc'd Cameron McCormack of Mozilla, as he was considering having the SVG
spec changed to use CSS tokenization.  However, that was before we considered
the above-quoted sections as to the purpose of presentation attributes in SVG.

In current practice, there's a lot of variation in each of the things that I've
tested.  Pure SVG software is often initially written without support for CSS,
and accordingly tends to get presentation attributes right (notwithstanding
the aforementioned non-compliant error handling of ignoring trailing garbage);
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.  (The most common case where I've encountered backslashes in SVG
documents is in URIs of resources hosted on a Windows system.)

pjrm.

Received on Monday, 18 February 2013 09:42:03 UTC