- From: Elliott Sprehn <esprehn@gmail.com>
- Date: Sun, 24 Mar 2013 02:50:11 -0400
- To: Dominic Cooney <dominicc@chromium.org>
- Cc: WebApps WG <public-webapps@w3.org>
- Message-ID: <CAPJYB1jnE+0+24oS--MrnZT+f8PmsBoD1wRcCGahTuha+_e-2Q@mail.gmail.com>
On Mon, Mar 18, 2013 at 4:48 AM, Dominic Cooney <dominicc@chromium.org>wrote:
> ...
>
> I think the offset{Parent, Top, Left} properties should be adjusted. This
> means that in the above example, b.offsetParent would be <body> and
> b.offsetLeft would be silently adjusted to accumulate an offset of 10px
> from c. I think this makes sense because typical uses of offsetParent and
> offsetLeft, etc. are used to calculate the position of one element in the
> coordinate space of another element, and adjusting these properties to work
> this way will mean code that naively implements this use case will continue
> to work.
>
> This behavior is unfortunately slightly lossy: If the author had #c and
> wanted to calculate the position of #b in the coordinate space of #c, they
> will need to do some calculation to work it out "via" body. But presumably
> a script of this nature is aware of the existence of Shadow DOM.
>
> The question of what to do for offset* properties across a shadow boundary
> when the shadow *is* traversable is a vexing one. In this case there is no
> node disclosed that you could not find anyway using .shadowRoot, etc. tree
> walking. From that point of view it seems acceptable for offsetParent to
> return an offsetParent inside the (traversable) shadow.
>
This seems like correct behavior. We should walk up to find a traversable
parent and then offsetLeft/offsetTop should be relative to those.
(Note in webkit this is trivial since offsetLeft, offsetTop both call
offsetParent internally and then compute their value from it)
>
> On the other hand, this violates the lower-boundary encapsulation of the
> Shadow DOM spec. This means that pages that are using traversable shadows,
> but relying on convention (ie "don't use new properties like .shadowRoot")
> to get the encapsulation benefits of Shadow DOM, now have to audit the
> offsetParent property. It also means you need to have two ways of dealing
> with offsetParent in both user agents and author scripts. So for simplicity
> and consistency I think it makes sense to treat both traversable and
> non-traversable shadows uniformly.
>
>
I disagree with this since it means offsetParent returns a nonsensical
value for elements in, or projected into, traversable shadow roots as it
traverses all the way up into the main page until it's not inside a
ShadowRoot anymore.
offsetParent is very useful to find your positioned parent, and you're
crippling that feature and making authors use distributedParent +
getComputedStyle() repeatedly which is considerably more expensive.
- E
Received on Sunday, 24 March 2013 06:51:18 UTC