- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 31 Aug 2010 11:36:36 -0400
- 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 http://hg.mozilla.org/mozilla-central/file/2b912044dfe7/layout/base/nsDisplayList.cpp#l1423 -Boris
Received on Tuesday, 31 August 2010 15:43:02 UTC