W3C home > Mailing lists > Public > www-svg@w3.org > January 2013

Re: Promoting more SVG attributes into properties

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 24 Jan 2013 10:24:50 -0800
Message-ID: <CAAWBYDDUer9W3fEpsd1xmiM1GgPYp5Uu9w--ufhj3wVG_zPEKg@mail.gmail.com>
To: Cameron McCormack <cam@mcc.id.au>
Cc: www-svg <www-svg@w3.org>
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?

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:40 UTC