Re: Promoting more SVG attributes into properties

On 24/01/13 5:54 AM, Tab Atkins Jr. wrote:
> The CSSWG today resolved to allow more SVG attributes into CSS
> properties, as requested by the SVGWG.  Starting from the list at
> <http://dev.w3.org/SVG/proposals/css-animation/animation-proposal.html#def_attributes>,
> we removed all the attributes that only have meaning within filters,
> and agreed to add the rest.

Great!

> This leaves us with the following list of attributes being promoted to
> properties:
>
> cx, cy, dx, dy, fx, fy, height, width, offset, r, rx, ry, x, x1, x2,
> y, y1, y2 and maybe d
>
> (d is a harder one - I *really* want it, but the syntax isn't
> compatible with CSS right now, and would require a reparse step to
> make it meaningful - for example, the valid path string "M0,0h1v1h1v1"
> produces three tokens in the CSS parser - IDENT(M0) COMMA DIMENSION(0,
> h1v1h1v1).  Are we interested in pursuing a more CSS-compatible syntax
> for path data?  Please say yes - I *really* want to be able to use
> units in path data, as I was *just* working on something made harder
> and uglier by that lack.)

I think from an authoring point of view it just makes sense to allow 
units in d="" (and in points="" on <polygon> and <polyline>).  If d="" 
it to eventually become a property, we should indeed consider a syntax 
that fits in with CSS better.  Last year we discussed having longer 
names for some of the new path commands, since the available Latin 
letters for them are obscure.  Maybe these new long names should only be 
available in this new CSS-friendly syntax?  (The presentation attribute 
could continue to accept the existing syntax but also the new syntax, if 
we design it right.)

> We accepted them as-is, without any name changes.  As these are
> properties, they parse with the usual CSS rules, which means no
> unitless lengths.

That's fine.

> The only issue is still that of collisions between attributes with the
> same name but different values, such as "x" on <rect> and <text>.  We
> can't reject mismatches at parse-time, like we usually do, because you
> can't tell whether it's wrong until you try to apply it.  There are a
> few ways to resolve this:
>
> 1. If the wrong syntax is used on a given element, treat it like an
> invalid variables, and just use the initial value for the property.

1a. Use the first value of 'x' on <rect> and ignore any subsequent values.

> 2. Restrict the property to a single syntax that works on both
> instances.  For example, for the 'x' property, only allow a single
> length.  If you want to specify multiple lengths for a <text> element,
> you need to use the attribute form.

I would prefer the model to be that the property is the actual storage, 
and the presentation attribute is just another way to influence the 
value of the property.  So I think the property needs to be able to 
represent both single values and a list.

If I can restate your #2: Have the 'x' property only represent a single 
position, which would be the first glyph position for a <text> element 
as usual.  The x="" presentation attribute on <text> would map to a 
single-valued property in the author style sheet with specificity 0. 
The remaining values in the attribute would still influence the position 
of subsequent glyphs, just not via the property.  (Remember that the use 
of multiple x/y positions on SVG text is discouraged, and we will at 
some point be introducing a mechanism to select and position glyphs from 
a font directly.)

I would be happy with any of these options.

Received on Thursday, 24 January 2013 05:37:59 UTC