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

On Aug 31, 2010, at 9:19 AM, Simon Fraser <smfr@me.com> wrote:

> On Aug 31, 2010, at 8:52 am, Brad Kemper wrote:
> 
>> On Aug 31, 2010, at 8:44 AM, Simon Fraser wrote:
>> 
>>>> 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).
>> 
>> It seems unexpected to me. I expect it to act more like position:relative. Can you explain why it makes more sense, and what use case would benefit by doing the child inlines separately?
> 
> Position: relative only lets you offset the boxes horizontally or vertically, so I don't think it informs on this issue. What do you expect to happen when a split <span> has a rotation transform?

> 
What I mean is that, like position:relative, I would expect the inline to leave behind a "hole" where it was, and then transform (restricted to translate transformations for position:relative) the whole span as a unit. I would expect the two lines of the broken span to remain anchored together in the same relationship to each other as they were before being rotated, with the same line widths, etc. 

I still don't understand why that wouldn't happen, or maybe I am misunderstanding what does happen? Is there something special about the BR, or is does the same thing happen when the text automatically wraps to a second line?

Received on Tuesday, 31 August 2010 19:10:31 UTC