[Webkit-unassigned] [Bug 71309] Allow SVG elements to be transformed using webkit-transform

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=71309





--- Comment #7 from Nikolas Zimmermann <zimmermann at kde.org>  2011-11-02 02:26:51 PST ---
(In reply to comment #5)
> (In reply to comment #4)
> > (From update of attachment 113204 [details] [details])
> > You're missing the changelogs. Also, why haven't you changed SVGTextElement as well? r-
> > 
> > Even so, I disagree with the implementation in general. I'd implement 'transform' as a CSS property and the transform attribute would be mapped to the CSS property.
I partly agree with Dirk, as long-term solution. The SVG transform attribute should be mapped to a unified CSS property, shared between CSS Transforms & SVG. This will resolve the problem, that you have to decide which property to take (which is what the current patch is doing).

> 
> Hmmm.. this is the implementation I was thinking of. We can't make "transform" a CSS property at the moment since the spec isn't done - it needs to be prefixed. Given that, it makes sense to take the first step here, which is to use the existing -webkit-transform style if it is present.
> 
> This also has the guarantee that any existing content that breaks will clearly be doing something wrong :) 
> 
> Later on we'll move it to an unprefixed "transform".
If that implies to switching SVG transform and both CSS transforms to this new unprefix CSS "transform" property, then I agree.

> 
> > I don't believe that this solution would help us a lot. Of course this needs more harmonization with the CSS parser and SVG DOM. I'd start rather with the CSS parser than with a separate implementation of 'transform' attr and  '-webkit-transform'.
> 
> I disagree, but I might not be fully understanding the reasoning behind your position. The approach in the patch seems to be the nicest first step: Zero change to any existing SVG content. Prefixed property to use CSS. Uses all the existing code for parsing/setting -webkit-transform.

If Raul and or other folks are continuing to work towards a unified unprefixed CSS property and this is only the first step, then I'm completely fine with it. Though I strongly think we shouldn't ever ship this as-is, even if the rule is "only if the prefixed -webkit-transform is specified, it has precedence over the SVG transform attribute".

Ok, say we take this route, then I'd request more testcases.

1)
Several code paths walk the transform hiearchy from a certain renderer up to RenderSVGRoot to figure out the absolute on-screen size, to create ImageBuffers for clipping/masking/patterns etc. in the correct size to avoid pixelation. This computed transform is then used to render on that ImageBuffer.
It's important that -webkit-transform is tested to work as well in this context.
eg.
<circle cx="10" cy="10" style="-webkit-transform: scale(10)" (with the transform origin set to match SVG of course)
used as clipPath.

2)
getCTM() on a -webkit-transform'ed <rect>. Test how SVGTransformList looks (should be identity, as currently SVG transform and -webkit-transform is decoupled). Very important!
We actually need tests that demonstrate which property currently has precendence!

3)
SVG transform and -webkit-transform set on a <rect>.
Dump SVGTransformList, dump CSS trafo, assure that they are not both applied currently.

4)
Influence on hit testing. Create copy of existing pointer-event / hittesting test cases, and replace some transforms by webkit-transforms, see if it still works :-)

....
I'd just like to be sure that we document the new behavior precisely, by tests.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.