Bug 70025 - Merge CSS and SVG Transforms according to CSS3 Transforms
Summary: Merge CSS and SVG Transforms according to CSS3 Transforms
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL: http://dev.w3.org/csswg/css3-transforms/
Keywords:
Depends on: 70026 71309 76437 79068
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-13 07:38 PDT by Raul Hudea
Modified: 2012-02-20 19:51 PST (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raul Hudea 2011-10-13 07:38:35 PDT
http://dev.w3.org/Graphics-FX/modules/2D-transforms/spec/2DTransforms.html

This is the tracking bug.
Comment 1 Dirk Schulze 2011-10-13 07:47:34 PDT
Can you explain more what you are planning to do? The SVG WG still did not make any decision on combining both transforms or supporting both next to each other. And replacing SVG Transform with CSS Transform would break a lot of content right now.
Comment 2 Raul Hudea 2011-10-13 08:57:02 PDT
(In reply to comment #1)
> Can you explain more what you are planning to do? The SVG WG still did not make any decision on combining both transforms or supporting both next to each other. And replacing SVG Transform with CSS Transform would break a lot of content right now.

Indeed, the decision on how the CSS property and the SVG attribute combine is not yet made, but until then, I'm currently investigating how this should be implemented:
- by either modify the CSS transform to handle SVG (more likely) or modify the current SVG tranform parser to match the FX spec
- how the SVG DOM should behave after the transform attribute becomes a property (the gathered knowledge here will be used to provide feedback to SVG group to make a resolution on this)

The plan is to start in small, incremental steps, making sure I'm not breaking any content. Right now, I'm still gathering knowledge in the SVG area.
Comment 3 Dirk Schulze 2011-10-13 09:41:03 PDT
(In reply to comment #2)
> (In reply to comment #1)
> > Can you explain more what you are planning to do? The SVG WG still did not make any decision on combining both transforms or supporting both next to each other. And replacing SVG Transform with CSS Transform would break a lot of content right now.
> 
> Indeed, the decision on how the CSS property and the SVG attribute combine is not yet made, but until then, I'm currently investigating how this should be implemented:
> - by either modify the CSS transform to handle SVG (more likely) or modify the current SVG tranform parser to match the FX spec
> - how the SVG DOM should behave after the transform attribute becomes a property (the gathered knowledge here will be used to provide feedback to SVG group to make a resolution on this)
> 
> The plan is to start in small, incremental steps, making sure I'm not breaking any content. Right now, I'm still gathering knowledge in the SVG area.

Sounds great. I'd also suggest to modify CSS transform. The last time I looked at the spec, CSS Transform was still missing some functionality of SVG Transform.

If you have questions or comments to SVG DOM feel free to meet SVG folks on IRC #ksvg.
Comment 4 Dean Jackson 2011-10-13 15:05:13 PDT
There is general consensus to move the SVG transform attribute to a CSS property. The spec hasn't been updated yet, but everyone agrees.

I've been talking to the folks at Adobe and we've come up with the following plan:

1. Have the SVG renderer use the RenderStyle::transform() rather than the transform attribute, in the case where the RenderStyle's transform is not null. This means no existing SVG content should break. People will be able to use CSS transforms on SVG through the -webkit-transform property (only via a style sheet). Note that the CSS property requires units (so you won't be simply able to copy an SVG transform attribute to a CSS property). This should also mean that CSS animations/transitions work.

2. Update the SVG DOM so that SVGTransformable (or whatever its called) reflects the CSS value if present (this might just work after step 1... sorry, haven't looked that deep in the code).

3. Now start to merge the transform attribute into a presentational attribute. As Dirk says, there are syntax differences, so maybe we'll still need two code paths - one to parse the property when specified as an attribute, and the existing CSS parser. Obviously we can't break existing content. We could also update the CSS parser to have a special mode when in the context of SVG, but I don't think that's a good idea. Or, we could add "px" in the right places in the attribute string before we pass it over to the CSS parser.

4. Support transform origin in SVG?

What happens when we get a 3D transform? There is a helper function that tells you, given a particular transform, if it is 3d or not. For now we could throw out any property value that isn't 3d in SVG. (It's a bigger project to rewrite the SVG renderer to use "layers" that can be composited and thus work with 3d)

Thoughts?
Comment 5 Dirk Schulze 2011-10-13 23:26:17 PDT
(In reply to comment #4)
> There is general consensus to move the SVG transform attribute to a CSS property. The spec hasn't been updated yet, but everyone agrees.
> 
> I've been talking to the folks at Adobe and we've come up with the following plan:
> 
> 1. Have the SVG renderer use the RenderStyle::transform() rather than the transform attribute, in the case where the RenderStyle's transform is not null. This means no existing SVG content should break. People will be able to use CSS transforms on SVG through the -webkit-transform property (only via a style sheet). Note that the CSS property requires units (so you won't be simply able to copy an SVG transform attribute to a CSS property). This should also mean that CSS animations/transitions work.
This is planned for SVG 2.0. The current spec won't be updated. Also consider that SMILAnimation code needs to get updated (but that shouldn't be that hard).

> 
> 2. Update the SVG DOM so that SVGTransformable (or whatever its called) reflects the CSS value if present (this might just work after step 1... sorry, haven't looked that deep in the code).
I suggested that on the telcon as well.

> 
> 3. Now start to merge the transform attribute into a presentational attribute. As Dirk says, there are syntax differences, so maybe we'll still need two code paths - one to parse the property when specified as an attribute, and the existing CSS parser. Obviously we can't break existing content. We could also update the CSS parser to have a special mode when in the context of SVG, but I don't think that's a good idea. Or, we could add "px" in the right places in the attribute string before we pass it over to the CSS parser.
IIRC Simon agreed to add the missing functionality to CSS Transforms. To the units, if you add the units automatically, how can you reflect this with SVGTransform? In SVG we differ between unit less values and values with units (even if unit less and applying 'px' is the same). Also CSS Transforms support some functions that are not supported by SVGTransform. We need a way to reflect this somehow in SVG DOM.

> 
> 4. Support transform origin in SVG?
> 
> What happens when we get a 3D transform? There is a helper function that tells you, given a particular transform, if it is 3d or not. For now we could throw out any property value that isn't 3d in SVG. (It's a bigger project to rewrite the SVG renderer to use "layers" that can be composited and thus work with 3d)
I'd handle it like in HTML when HW acceleration is disabled. Means Ignore z-value in origin and transform 3dtransforms to 2dtransforms. Origin attribute will be supported in SVG 2.0.

Just another note: The origin default value differs between HTML and SVG. For SVG it needs to be (0%,0%) to the bounding box.
Comment 6 Dean Jackson 2011-10-14 03:54:05 PDT
(In reply to comment #5)

> > 3. Now start to merge the transform attribute into a presentational attribute. As Dirk says, there are syntax differences, so maybe we'll still need two code paths - one to parse the property when specified as an attribute, and the existing CSS parser. Obviously we can't break existing content. We could also update the CSS parser to have a special mode when in the context of SVG, but I don't think that's a good idea. Or, we could add "px" in the right places in the attribute string before we pass it over to the CSS parser.

> IIRC Simon agreed to add the missing functionality to CSS Transforms. To the units, if you add the units automatically, how can you reflect this with SVGTransform? In SVG we differ between unit less values and values with units (even if unit less and applying 'px' is the same). 

Yeah, I don't really think adding px to the string before sending it to CSS is a good idea. It's better to update the CSS side - adding the features to get on par with SVG (I think the big one is rotation origin).

> Also CSS Transforms support some functions that are not supported by SVGTransform. We need a way to reflect this somehow in SVG DOM.

I don't know if we have to address that until we want to support 3d.

> > 4. Support transform origin in SVG?
> > 
> > What happens when we get a 3D transform? There is a helper function that tells you, given a particular transform, if it is 3d or not. For now we could throw out any property value that isn't 3d in SVG. (It's a bigger project to rewrite the SVG renderer to use "layers" that can be composited and thus work with 3d)
> I'd handle it like in HTML when HW acceleration is disabled. Means Ignore z-value in origin and transform 3dtransforms to 2dtransforms. Origin attribute will be supported in SVG 2.0.

I'm not very keen on this. I'd prefer to just ignore the property value, because it allows people to author their CSS in a manner that supports a fallback. In the future we'll support 3d in SVG, but for now people could write:

transform: scale(2) rotate(10deg);
transform: scale(2) rotateY(10deg);

This way they still get to control the effect when 3d is not available. Also, flattened 3d transforms look horrible :)

> 
> Just another note: The origin default value differs between HTML and SVG. For SVG it needs to be (0%,0%) to the bounding box.

Do we have to worry about that yet? Only when SVG supports the transform-origin property - then we'll need code to test whether it is in SVG or CSS.
Comment 7 Dirk Schulze 2011-10-14 04:27:39 PDT
(In reply to comment #6)
> (In reply to comment #5)
> > I'd handle it like in HTML when HW acceleration is disabled. Means Ignore z-value in origin and transform 3dtransforms to 2dtransforms. Origin attribute will be supported in SVG 2.0.
> 
> I'm not very keen on this. I'd prefer to just ignore the property value, because it allows people to author their CSS in a manner that supports a fallback. In the future we'll support 3d in SVG, but for now people could write:
> 
> transform: scale(2) rotate(10deg);
> transform: scale(2) rotateY(10deg);
> 
> This way they still get to control the effect when 3d is not available. Also, flattened 3d transforms look horrible :)
Sure, but it would help in the meantime. I don't think that you want to deny 3D code in -webkit-transform
for SVG if we will support it later anyway.

> 
> > 
> > Just another note: The origin default value differs between HTML and SVG. For SVG it needs to be (0%,0%) to the bounding box.
> 
> Do we have to worry about that yet? Only when SVG supports the transform-origin property - then we'll need code to test whether it is in SVG or CSS.

I'm not sure. But I think I can remember that it was a problem. IIRC you had to pass the you bounding box at some point and that is used to calculate the origin for the transform. I definitely didn't thought about implementing transform-origin property at this time. Sadly I don't find my patch where I enabled CSS transforms in parallel to SVGTransforms. I'll search it later again.
Comment 8 Raul Hudea 2011-10-14 05:01:27 PDT
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > I'd handle it like in HTML when HW acceleration is disabled. Means Ignore z-value in origin and transform 3dtransforms to 2dtransforms. Origin attribute will be supported in SVG 2.0.
> > 
> > I'm not very keen on this. I'd prefer to just ignore the property value, because it allows people to author their CSS in a manner that supports a fallback. In the future we'll support 3d in SVG, but for now people could write:
> > 
> > transform: scale(2) rotate(10deg);
> > transform: scale(2) rotateY(10deg);
> > 
> > This way they still get to control the effect when 3d is not available. Also, flattened 3d transforms look horrible :)
> Sure, but it would help in the meantime. I don't think that you want to deny 3D code in -webkit-transform
> for SVG if we will support it later anyway.

I'm also inclined to agree with supporting the flattened 3d transform in SVG, because they will also exist when hw acceleration is disabled.

> 
> > 
> > > 
> > > Just another note: The origin default value differs between HTML and SVG. For SVG it needs to be (0%,0%) to the bounding box.
> > 
> > Do we have to worry about that yet? Only when SVG supports the transform-origin property - then we'll need code to test whether it is in SVG or CSS.
> 
> I'm not sure. But I think I can remember that it was a problem. IIRC you had to pass the you bounding box at some point and that is used to calculate the origin for the transform. I definitely didn't thought about implementing transform-origin property at this time. Sadly I don't find my patch where I enabled CSS transforms in parallel to SVGTransforms. I'll search it later again.

I was just looking at this and the bounding box is needed when transform-origin is percent-based.