1208113 - Nested custom elements don't apply correctly scoped styles

Status: RESOLVED WONTFIX

(Core :: CSS Parsing and Computation, defect, P2)

Description

[Julien Wajsberg [:julienw]]

Attachment: index-simplified.html

I'm not completely sure of this one, maybe I'm doing something wrong.

Please open the attachment. You'll see that "outsider div" is green with a border. But this scoped style is appended to the innermost custom element that does not contain "outsider div". Moreover, it's inside a shadow root.

Therefore I believe "outsider div" should be unstyled, black, like "Insider div".

Note that this triggers an issue with some Gaia use of custom elements.

Comment 1

[Julien Wajsberg [:julienw]]

I'm using such a construct in bug 1207093. While I could likely workaround it, it would be better if the Gecko bug (if there is actually a bug) is fixed.

Comment 2

[Julien Wajsberg [:julienw]]

[Blocking Requested - why for this release]:

This is making working with nested web component quite miserable at the moment. At least the way we use them in Gaia.

Comment 3

[Mahendra Potharaju [:mahe]]

Hema, Can you help triage this and see if its a blocker?

Thanks

Comment 4

[William Chen [:wchen]]

Scoped style sheets don't actually work properly inside shadow DOM (and XBL) right now which is causing the problem you are seeing. Rather than being scoped, the style applies to all the contents of the shadow DOM. On initial investigation it doesn't look like it'll be a simple fix and I'll need to look into it more.

Comment 5

[Mahendra Potharaju [:mahe]]

Setting the blocker flag.

Comment 6

[Andrew Overholt [:overholt]]

This isn't going to land in 44 (for 2.5).

Comment 7

[Mahendra Potharaju [:mahe]]

[Blocking Requested - why for this release]:

Julien, 

Can you please tell if this needs to be a blocker? Its not landing in 44

Comment 8

[Julien Wajsberg [:julienw]]

It's OK because bug 1207093 is not due for 2.5 either. (and anyway we can workaround it even if it's not always easy).

Comment 9

[Julien Wajsberg [:julienw]]

But note this is really important for proper web component experience, not only for B2G but also for Desktop.

Comment 10

[Mahendra Potharaju [:mahe]]

[Tracking Requested - why for this release]:

Thanks Julien. Will set the backlog flag so it will tracked post 2.5.

Comment 11

[Julien Wajsberg [:julienw]]

So, as usual, no blocker means nobody works on this. We're now 1 month after last comment.

Andrew, when do you think this could be fixed? This is important...

Comment 12

[Andrew Overholt [:overholt]]

William and I just discussed this and it's not something that's easy to fix. Can you elaborate a bit on what you're trying to use this for? William said he may be able to come up with a workaround in the short term.

(I would love to chat about the not-a-blocker-means-no-work situation when we meet in person some time)

Comment 13

[Chris Lord [:cwiiis]]

While it doesn't block homescreen work, this is making style pretty tedious to write in some situations - having to add work-arounds that make the style and code harder to read than it otherwise would be.

Comment 14

[Julien Wajsberg [:julienw]]

In my case, I was working on bug 1207093. I'm writing a component that's using itself another component (gaia-button). It happens that this component uses some buttons as well, that are outside of the nested component.

You can look at my workarounds in [1] and [2] (12 lines of code just to workaround this issue).

See [3] for the full affected PR.

[1] https://github.com/julienw/gaia/blob/1066ab34cdab12b591df4d444906c3e2dea92346/shared/elements/gaia_confirm/style.css#L101-L110
[2] https://github.com/julienw/gaia/blob/1066ab34cdab12b591df4d444906c3e2dea92346/shared/elements/gaia_confirm/style.css#L115-L118
[3] https://github.com/mozilla-b2g/gaia/pull/31978


So I created a simpler testcase in attachment 8665496 [details] in the hope it would speed things up :)



My main concern here is simple: the feature is broken. Whether it's difficult to fix is not the right question. The right question is whether we need to fix it. And my answer here is yes: we have to fix it because it's a big issue. It's not an edge case.

Comment 15

[Wilson Page [:wilsonpage]]

If I understand this issue correctly, I think is would be better to live with workarounds[A][B] and free up platform team to finish our Shadow DOM implementation.

We should have no reason to use `<style scoped>` inside a Shadow Root if we get the missing Shadow CSS selectors (`:host`, `:host-context`, `::slotted`) in Gecko.

FWIW moving forward, <gaia-buttons> is deprecated.

---

[A] Override leaking styles.
[B] Don't use generic CSS selectors inside a component that is likely to be nested.

Comment 16

[Julien Wajsberg [:julienw]]

To be clear: I don't really mind what we fix when, what I want is a path towards having a great web component implementation.

The workaround [A] is a major inconvenience (especially that it takes some time to understand what's going on), the workaround [B] is very unfortunate. Any path towards eliminating these issues is good to me. But I want a path.

Comment 17

[Emilio Cobos Álvarez (:emilio)]

<style scoped> is gone.