W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: [CSSOM] Interaction of getBoundingClientRect/getClientRects with transforms

From: Simon Fraser <smfr@me.com>
Date: Tue, 31 Aug 2010 08:44:50 -0700
Cc: www-style list <www-style@w3.org>
Message-id: <CA701F1A-3551-4C87-9B38-99B57A1F96C3@me.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>
On Aug 31, 2010, at 8:36 am, Boris Zbarsky wrote:

> On 8/31/10 11:20 AM, Simon Fraser wrote:
>> On Aug 31, 2010, at 6:30 am, Boris Zbarsky wrote:
>>> On 8/31/10 9:13 AM, Anne van Kesteren wrote:
>>>> Bounding box is what we do for SVG so we should do that here too.
>>> So for each box generated by the element, return the coordinates of its bounding box?  Think this:
>>>  <span id="transformed-span">Some<br>text</span>
>> WebKit doesn't support transforms on inlines (yet) because we're not smart enough to handle this case. The transforms spec doesn't  actually say what the rendering should be here.
> Apart from transform-origin being underdefined if the element generates multiple boxes, is there any other spec problem here?

No, that's the primary issue that the spec does not yet address.

An alternative would be to change the spec to say that transforms do not apply to inline elements.

> For what it's worth, Gecko's behavior here is to determine a separate transform-origin for each box that's generated and then apply the transform to each box separately.  This means that something like:
> <span style="-moz-transform: rotate(45deg);">x<br>x</span>
> gets rendered with the two boxes offset from each other vertically by the line height and not offset horizontally and each rotated by 45 degrees clockwise.

That's probably what we'd want to do in WebKit. It's a bit odd, especially with rotations, but I think it makes more sense than transforming  all the boxes together (even though that would be easier for us to implement).

Received on Tuesday, 31 August 2010 15:45:29 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:49 UTC