[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 02:26:52 PDT 2011
--- 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.
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.
<circle cx="10" cy="10" style="-webkit-transform: scale(10)" (with the transform origin set to match SVG of course)
used as clipPath.
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!
SVG transform and -webkit-transform set on a <rect>.
Dump SVGTransformList, dump CSS trafo, assure that they are not both applied currently.
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.
More information about the webkit-unassigned