Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn <esprehn@gmail.com> wrote:

>
> 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
>

Which part?

Returning an element inside Shadow DOM in an attribute of a node outside
Shadow DOM violates lower boundary encapsulation.

If offsetParent returns an element inside traversable Shadow DOM, pages
that are using traversable shadows but relying on convention to get
encapsulation benefits will have to audit uses of the offsetParent property.

If offsetParent returns an element inside traversable Shadow DOM (but not
non-traversable Shadow DOM), there are two ways of dealing with
offsetParent in the user agent.

If offsetParent returns an element inside traversable Shadow DOM (but not
non-traversable Shadow DOM), there are two ways of dealing with
offsetParent in author scripts.

It makes sense to treat both traversable and non-traversable shadows
uniformly.


> 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.
>

In what way is that nonsensical? The return value makes sense at the level
of abstraction the code calling innerParent is working at.


> 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.
>

What are those use cases, except finding the position of an element
relative to another element, which I think is not excessively complicated
by what I am proposing here?

Dominic

Received on Monday, 25 March 2013 06:49:00 UTC