(Offtopic) Allowing use of CSS syntax in SVG presentation attributes

On Wed, May 23, 2012 at 01:24:04PM +1000, Cameron McCormack wrote:
> Bjoern Hoehrmann:

> >And as far as I can tell from a brief look at "current" specifications,
> >
> >   fill="url(o\000308)"
> >
> >and
> >
> >   background-image: url(o\000308);
> >
> >refer to different resources [because \000308 in the latter involves CSS
> >escape interpretation, whereas the former is a literal string: XML uses &
> >escapes, and assigns no special meaning to backslashes in attribute strings].
> >If you want to have CSS comments and CSS escapes in presentation attributes
> >in SVG then we could talk about using CSS url tokens in SVG, otherwise you
> >will have to stick to 'funcuri's.

It might nevertheless make sense to use the same names as CSS, so that one can
use the same grammar productions for presentation attribute values as the
corresponding CSS property values.

> OK.  I think it's worth us (SVG) considering changing to using CSS
> syntax inside presentation attributes.

(Given the context of the o\000308 example, I'm taking "CSS syntax" to mean CSS
lexing.  I believe that SVG uses already shares the same grammar with CSS and
XSL for properties like font-family, and that it currently shares lexical
definitions with XSL rather than CSS.)

I'd be concerned about the implementation impact on SVG Tiny / SVG Mobile user
agents, which currently don't need to support the style attribute or style
element:

  # 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.

There is the option of changing only SVG full to use CSS lexing without
changing SVG Tiny; though I don't see that being an attractive option myself.

When working on Inkscape, I don't recall it being a burden on implementation
that we couldn't use a CSS lexer for parsing presentation attributes, whereas I
do remember it being a burden to have to use a CSS lexer elsewhere.

One of the challenges facing SVG, and a reason that wikipedia currently doesn't
serve SVG images, is limited interoperability among current implementations.

I have experience in only one SVG implementation, but my guess is that
interoperability would reduce rather than increase if presentation attributes
were to be specified to use CSS lexing.

> (Unitless lengths and scientific notation of course being the ones
> presentation attributes will still need to support.)

The fact that there are still some differences does slightly weaken the case
for change.

> I think the group is keen to reduce the number of differences, where we can.

I imagine that that comment is partly based on the discussions concerning
scientific notation.  I'd note that some of the arguments raised on that
subject don't apply to adopting CSS escaping or CSS comments, and some would
even work the other way.  (Though some of the arguments raised then would also
apply in support of adopting CSS escaping or CSS comments.)


If I seem negative towards the change, I should note that I wasn't involved in
the F2F or telcon discussions where this sort of subject has been discussed, 
so I'm not well placed to make a sound evaluation overall.

> A quick check with
> 
>   http://people.mozilla.org/~cmccormack/tests/pres-attr-syntax.svg
> 
> shows in presentation attributes Gecko and WebKit both understanding
> a CSS escape, only WebKit understanding a CSS comment, and Opera
> understanding neither.

[Arguably "misunderstand" would be a more appropriate word given that
 Gecko and WebKit are violating the current spec in that behaviour :) .]

Both Inkscape and librsvg follow Opera (and I believe the spec) for that
example.

pjrm.

Received on Thursday, 14 June 2012 05:20:28 UTC