Re: CSS Animation and Transitions on SVG attributes

Hi,

I would like to follow up on this. I think that we discussed this during the Hamburg FX face to face:

On Feb 22, 2012, at 4:37 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Wed, Feb 22, 2012 at 3:37 PM, Patrick Dengler <patd@microsoft.com> wrote:
>> I have not seen any more responses to this thread (perhaps I missed them?).
>> We identified this as a high priority issue in August of 2010 and we have
>> been discussing in the SVG/CSS FX task force for well over a year. We
>> collectively made the resolution to address this issue with the CSS/SVG FX
>> task force at TPAC in 2010; I was asked to write it up more recently and
>> would like to close if this is possible.
>> 
>> This proposal was the resolution reached by the SVG Working Group at the
>> last face-to-face at the end of last year.  Many of the members of the CSS
>> working group have been a part of the discussion. The same issues keep
>> arising and we tend to eventually land on the same resolutions.  I ask you
>> as graciously as I can that we either find new issues, choose different
>> resolutions or resolve this.  I’m not married to any one direction but do
>> believe after owning this for so long, that this is the right thing to do.
>> 
>> What are the appropriate steps to reach resolution?
> 
> I am okay with the proposal as it now stands.
> 
> I'm not *super* happy with the couple of extra-short names, but
> they're okay.  I think that prefixing all of the SVG properties would
> be bad (because some are already unprefixed, and some new ones share
> names with existing properties), and prefixing only some of them would
> be similarly bad because it's inconsistent and hard to remember.
> 
> I would like, eventually, for SVG's layout model to integrate with CSS
> more fully, but I'm okay with that taking time, and it in no way
> blocks the current work.
> 
> I don't think it's correct, as you assert, that resolving left/top vs
> x/y isn't germane to this effort.  It's very relevant, but I think
> that trying to match SVG to the Positioned Layout model wouldn't work
> very well.

x -> top and y -> left
is not very future proof. We may want to have SVG elements in HTML content directly (without <svg>...</svg> around the element), or at least keep this possibility open. If we would do that, these elements contribute to the CSS boxing model. This can lead to bigger issues with coordinate space and others. I can give more explicit examples if requested.


The second thought is about the two proposals 1) prefix properties with svg-* 2) new names for short properties (e.g. r -> radius).

I know that some people in the CSS WG didn't feel very comfortable with these short names and asked for creating long names.
The SVG WG defined the short names a very long time ago. SVG 1.0 was proposed back in 2000. There is a lot of content using these attributes so a lot of content authors are already familiar with them. With high DPI screens, SVG gets more and more important. With HTML(5) it is easier then ever to embed SVG files directly into the document. I strongly believe that the use of SVG will increase over the next years. Nearly every page with diagrams or graphics about the US election this year used SVG. It can not longer be denied that SVG is important for the web.

The argument that content authors are not familiar with SVG and may not understand these short names is not valid anymore. If you like the attribute names or not, we all have to live with them. It would be extremely unnatural for all these content creators if all these attributes can be styled, but they need to use a different name to set the same attribute. People would need to learn two sets of names, the attribute names and the appropriate property names.

Please look beyond the current concerns and consider what. Please consider that we (and especially content creators) have to live with the decision in the future that we make now.

I strongly recommend to map as many attributes from SVG to CSS properties one by one (where CSS animations make most sense) as possible.

Greetings,
Dirk

PS: We would still need to discuss some edge cases: x, y on <text> would most probably need tweaks anyway but can stay attributes in a first draft; camel case names should be case insensitive in CSS and so on.
> 
> ~TJ
>

Received on Thursday, 20 December 2012 04:25:31 UTC