- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 31 Aug 2010 07:13:19 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: www-style list <www-style@w3.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Tue, Aug 31, 2010 at 6:13 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Tue, 31 Aug 2010 14:57:45 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> >> How should getBoundingClientRect/getClientRects (which assume that the >> element they're called on decomposes into a set of axis-aligned boxes) >> interact with transforms? >> >> For a simple testcase of a single transformed div with the functions >> called on it, Gecko reports the rect the div would have if the transform >> were not applied. Webkit and Presto seem to report a bounding client rect >> for the transformed div (so for the case of a 100x100 px square rotated >> 45deg clockwise about the bottom-left corner they report 142px width and >> height and 29px top). See testcase at end of mail. >> >> The spec probably needs to say what the right behavior is here. (And of >> course also for offset* and whatnot, but at the moment I'm more concerned >> about getClientRects.) > > Bounding box is what we do for SVG so we should do that here too. Ideally > the definition of "border box" in CSS reflects this behavior or CSS gets a > different kind of "border box" that reflects this behavior and CSSOM View is > updated to use that. Given that transforms don't affect the geometry, I'd assume that the current non-transform-aware definition of "border box" should be the appropriate one here. (I'm curious about how a transformed element works when used in a background with the -moz-element() function or the -webkit-canvas() function, particularly with background-repeat:repeat.) ~TJ
Received on Tuesday, 31 August 2010 14:14:08 UTC