W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2011

RE: CSS Animations Targeting SVG attributes

From: Patrick Dengler <patd@microsoft.com>
Date: Tue, 15 Mar 2011 21:10:36 +0000
To: "robert@ocallahan.org" <robert@ocallahan.org>, Tab Atkins Jr. <jackalmage@gmail.com>
CC: Dean Jackson <dino@apple.com>, "public-fx@w3.org" <public-fx@w3.org>
Message-ID: <4A2DB3AE4504E944AF122BBFBA7FBA1F5829277F@TK5EX14MBXC118.redmond.corp.microsoft.com>
This is great.  One more thing I was considering. On the 2nd proposal, instead of using the “attr-“ we might consider “svg-”.  This could head off issues around understanding as well as leave flexibility for any other attribute story in the future.  Maybe I just like it.

From: public-fx-request@w3.org [mailto:public-fx-request@w3.org] On Behalf Of Robert O'Callahan
Sent: Tuesday, March 15, 2011 1:17 PM
To: Tab Atkins Jr.
Cc: Dean Jackson; public-fx@w3.org
Subject: Re: CSS Animations Targeting SVG attributes

Thanks for doing that! A few corrections of the top of my head:

You seem to be missing x/y/width/height for 'rect'.
x/y for tref/tspan also apply to 'text'.
dx/dy for 'text' are actually a length-list.

A few observations:

width/height on foreignObject and rect should be uncontroversial to map to CSS width/height.
It looks like the biggest problem with attribute name overloading is just x/y for tref/tspan/text vs rect/foreignObject. That's encouraging.
It looks like very few of these map cleanly onto existing CSS properties. There's 'transform', plus we could let x/y for rect and foreignObject map to top/left maybe (that would deal with the overloading problem for those attributes), and we could let rx/ry on rect map to border-radius maybe. I don't see any other obvious mappings. That's less encouraging.

"Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
Received on Tuesday, 15 March 2011 21:11:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:38 UTC