Re: Promoting more SVG attributes into properties

On Wed, Jan 23, 2013 at 9:38 PM, Cameron McCormack <cam@mcc.id.au> wrote:
> On 24/01/13 5:54 AM, Tab Atkins Jr. wrote:
>> 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.)

Ah, that's probably a good idea.  And yeah, I think it shouldn't be
hard to make them distinguishable.  I might work on this today.


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

Ah yeah, that's probably the best option for that collision.  Are the
other collisions similarly resolveable?

~TJ

Received on Thursday, 24 January 2013 18:25:37 UTC