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

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 31 Aug 2010 11:36:36 -0400
Message-ID: <4C7D2184.3010401@mit.edu>
To: Simon Fraser <smfr@me.com>
CC: www-style list <www-style@w3.org>
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?

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.

The other option would be to use a single transform origin for all the 
boxes; that would render as two boxes offset vertically by 1/sqrt(2) * 
line-height and horizontally by the same amount and then rotated (so the 
post-transform "top" corner of the second box would coincide with the 
post-transform "left" corner of the first box).

We have code for the second model, ifdefed out, but it's not clear to me 
what the long-term plan is.  See 

Received on Tuesday, 31 August 2010 15:43:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:38 UTC