- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 24 Jan 2013 16:38:16 +1100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: www-svg <www-svg@w3.org>
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