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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Nov 2 08:17:04 PDT 2011


--- Comment #9 from Raul Hudea <rhudea at adobe.com>  2011-11-02 08:17:04 PST ---
(In reply to comment #7)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (From update of attachment 113204 [details] [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".

This is only the first step, as the final goal is to unify both CSS and SVG transforms.

> 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 :-)

Thanks for the new tests suggestions. I will add them.

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

More information about the webkit-unassigned mailing list