1583562 - Incorrect offset measurement when using shadow dom

Status: RESOLVED INVALID

(Core :: DOM: Core & HTML, defect)

Description

[cary.j.smith]

Attachment: example.html

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.75 Safari/537.36

Steps to reproduce:

I have two custom elements with shadow-dom, each with a slot. One element uses the other as part of its template. Both elements have "position: relative" wrapping of the slot as part of their template. The outer element has some padding, the inner one does not.

Actual results:

When placing regular dom inside the custom elements and retrieving the offsetLeft property for calculation purposes, it is reporting the offsetLeft according to the outer element (i.e. including the padding).

Expected results:

The offsetLeft (I have not checked other properties) should be reported according to the projection placement which is the inner custom element not the outer. Otherwise calculations become far more complex when using complex combinations of custom elements.

Comment 1

[cary.j.smith]

JSBin version if you like: https://jsbin.com/tenuhagefu/edit?html,js,output

Comment 2

[Liviu Seplecan]

Hi @cary.j.smith, tested the issue & here are the results:
[Platform affected]: Windows 10, Mac OS X, Ubuntu 18.04
[FF Environment]: nightly 71.0a1, beta 70.0b10, release 69.0a1
=> on all machines and environments the issue can be reproduced.
Additionally in other browsers works accordingly.
Regards,
Liviu

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Safari behaves the same as us. This is actually a bug in Chrome, see https://github.com/w3c/csswg-drafts/issues/159.

offset* properties are relative to offsetParent, and offsetParent shouldn't leak a node inside a shadow tree.

Comment 4

[cary.j.smith]

Although this may be considered a bug in Chrome, I am rather confused about how this helps encapsulation of element functionality and styling.

If component A is used as a part of the template of component B, it cannot measure nested light dom elements accurately because it has to accommodate for element B if uit uses a shadow dom template. This seems to violate the encapsulation idea because component A should only have to worry about itself. If component A provides a "position: relative" wrapper of a slot, then the offsetLeft value seems like it should be based on that.

I understand Safari may do it that way as well and can see the argument for accidental exposure of an 'internal' element, but it also makes composition using smaller, more focused structures harder... especially if the components can be used separately too. When element A is used on its own the offset values is one thing, but when used as part of a template in element B it is something different. Is it more desirable to require elements to know how they are being used (parent walking) to get consistent measurements? I really am confused because the render places the light dom in the correct position (relative to element A's slot wrapper) but provides offset information from element B's slot wrapper.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Probably that CSSWG issue is the one to discuss about this stuff.

Funny thing is that it's the Google people who filed it and agreed to do the same as Safari and Firefox do... Yet they never did :)

But it seems to me that leaking an element from a nested shadow tree that isn't supposed to be there is just a no-go.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

To be clear, it doesn't help encapsulation of the outer component. But if I can just do offsetParent.style.position = "static" I can just break the inner shadow tree, which has nothing to do with all this.

Comment 7

[cary.j.smith]

Fair enough. I definitely do not wish to expose internal workings of components but do hope for consistent feedback when using them. It just complicates some of the math and requires the component be more aware of its placement (parent) which feels very brittle to me. Maybe there is a better pattern I have not yet found.

Thanks for looking into it.