Re: [css3-transforms] translate() vs. translate3d()

Hello,

I tried to show that there are a lot of use cases for SVG and that I believe that there will be use cases in CSS as well. But I also want to show you the SVG perspective:

SVG exist for more than 12 years. A lot of content was created since then. Try to search for SVG as filetype by using "filetype:svg" on google. You will find more than 140,000,000 SVG files. This doesn't include inline SVG's in HTML documents that are more popular with HTML5 nowadays. It doesn't include SVGs created with RaphaelJS, jQuery or d3. Even Wikipedia uses thousands of SVGs for demonstrations.

Given the overwhelming count of files the SVG WG has a great interest not to break existing content. But transformations are the most important part of SVG. So the step to a merged transform specification with CSS is a great step and we must make sure that SVG stays backward compatible. Now that all major browsers support SVG, it will be a great benefit for all parties to have a common implementation of transforms. It helps to join forces for a future aware implementation.

To be consistent I want to make sure that everything that is possible with SVG now, will still be possible after the merging process. A lot more than just parsing is involved in this process. The parsing could be different for SVG, and a rotate with 3 arguments could easily transformed to a rotate with one argument and two translations in the background. But SVG has a very powerful feature called SVG DOM.

SVG DOM provides interfaces to access every single transformation function. You can not only modify transformation functions and the values in the matrices, you can also change the order of transformation functions in the transformation functions list, remove functions from the list, add new functions and so. There is a lot of content that uses the interfaces called SVGTransformList, SVGTransform and SVGMatrix extensively. If we would replace the rotate with three arguments by two translations and one rotate, it would influence the SVG DOM as well. Instead of one rotate, the list would have two more functions. This would definitely break some content. You could try to handle this by the backend as well. But this would be very complicated and you can not guarantee that it works all the time.

You said that you don't care that much about the needs of SVG in one of your previous mails. Well, a lot of people do care. And a lot of them wrote the 140,000,000 SVG files. I, as a member of the SVG WG, do definitely care about SVG. Nevertheless I understand that implementers want to reduce changes on the current implementation as much as possible. I don't want bigger changes either so that we can get to a WD as soon as possible. But a minimum is needed to provide the necessary backward compatibility. And surprisingly rotate with three arguments is the one of the changes t provide the backward compatibility that we need. The rest is already in the CSS Transform specification and just needs some more explanation on the SVG side (like handling of SVG DOM on a CSS Transform, using of SMIL Animations and so on).

I hope this clarifies why I proposed the two optional arguments. The best on that: it doesn't break backward compatibility on CSS 2D transforms and it is easy to implement it. Mozilla, Opera, IE and WebKit have experience in that for their SVG implementations.

Greetings,
Dirk

PS: I bet 140,000,000 SVG files are even more than the count of used '-webkit-' prefixed properties in the web ;)


On Feb 10, 2012, at 3:17 PM, Dirk Schulze wrote:

> 
> On Feb 10, 2012, at 8:35 AM, Aryeh Gregor wrote:
> 
>> On Fri, Feb 10, 2012 at 10:27 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>>> I added the two offset arguments for rotate() yesterday. While for Rotate3d you specify a vector to define the aches around you want to rotate the element in 3d space, rotate() defines an offset to the origin. And you rotate the element around this given point. So it is hard to combine both functions and separating makes more sense then.
>>> 
>>> Note that rotate excepts length and percentage, while rotate3d just excepts numbers (vector).
>> 
>> Browsers do not implement this in CSS.  Do they plan to?  I think the
>> extra arguments are confusing -- they're redundant to
>> transform-origin,
> That is incorrect. transform-origin applies to a list of transformation functions. With the optional arguments you can specify it for rotate explicitly, independent of the other transformation functions.
> 
>> and they aren't present for matrix()
> Well, it doesn't make sense for matrix, no?
> 
>> or scale*() or
>> skew*(), where they're equally relevant.  
> I agree in this point. There is/was a bug report about that and I would be open for this change.
> 
>> They might have made sense
>> in SVG, which had no transform-origin, but I don't think they belong
>> in CSS.  
> Like I said, this is independent of transform-origin. Authors use a list of transformation functions quite often.
> 
>> I don't think complicating CSS is a good cost to pay to bring
>> it more in line with SVG.
> I don't think that two _optional_ arguments for the rotation point are more complicated. All existing contents will still work. S you don't have to argue that it will break the web. Also it is used quite often in SVG, so it looks like authors are interested in it. And like I said, this is independent of transform-origin. And also, CSS Transform will be a _merged_ specification between SVG Transform and CSS 2D/3D transforms, why shouldn't we look at SVG? When authors use it on SVG even if they could choose different ways today, why shouldn't CSS authors avoid it?
> 
>> 
>> Regardless, this kind of thing needs to be decided by implementers.
>> Do they want to implement the extra two arguments to rotate()?  If so,
>> then sure, let's keep them.  If not, I strongly feel they should be
>> removed from the spec.
> I would implement it for WebKit, yes. If there should be a consensus to remove this function, than yes it will be removed again.
> 
> Greetings,
> Dirk
> 
>

Received on Saturday, 11 February 2012 04:26:00 UTC