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

RE: [css3-2d-transforms][css3-3d-transforms] Clarify equivalency with position: relative

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Sat, 30 Oct 2010 01:01:51 +0000
To: David Hyatt <hyatt@apple.com>
CC: www-style list <www-style@w3.org>
Message-ID: <045A765940533D4CA4933A4A7E32597E2879C8E2@TK5EX14MBXC111.redmond.corp.microsoft.com>
> From: David Hyatt [mailto:hyatt@apple.com]
> Sent: Friday, October 29, 2010 5:28 PM
> To: Sylvain Galineau
> Cc: www-style list
> Subject: Re: [css3-2d-transforms][css3-3d-transforms] Clarify
> equivalency with position: relative
> 
> On Oct 29, 2010, at 6:21 PM, Sylvain Galineau wrote:
> 
> > Related to this is whether transforms should affect CSSOM properties
> > such as offsetLeft.
> >
> 
> I do think an element that specifies a transform should be an
> offsetParent.  We don't currently do this in WebKit, but I think we
> should.  It's conceptually similar to IE's CSS "zoom" property (which
> WebKit also supports), and that property causes you to become an
> offsetParent when specified I believe (I did that in WebKit at least,
> and I assume I did it to match IE).
> 
> I don't think offsetLeft etc. should be affected by the transform
> simply because it can be something other than a simple translation or
> scale.
> 
> dave
> (hyatt@apple.com)

Given that transforms result in the creation of a stacking context
and offsetParent generally maps to the element's containing block,
this is likely true in many cases today. But I'm not sure what you
get out of that if your offsetTop/offsetLeft are unchanged. There is
a lot of code out there that walks up the offsetParent chain adding
offset tops/lefts along the way to figure out the position of a new
element or effect. If there is a transform along the way that kind of
logic will no longer work whatever offsetParent says.
Received on Saturday, 30 October 2010 01:02:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:33 GMT