Closed Bug 1208113 Opened 4 years ago Closed Last year

Nested custom elements don't apply correctly scoped styles

Categories

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

defect

Tracking

()

RESOLVED WONTFIX
tracking-b2g backlog
Tracking Status
firefox44 --- affected

People

(Reporter: julienw, Unassigned)

References

Details

(Whiteboard: [platform])

Attachments

(1 file)

Attached file 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.
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.
Blocks: 1207093
Flags: needinfo?(wchen)
[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.
blocking-b2g: --- → 2.5?
Hema, Can you help triage this and see if its a blocker?

Thanks
Flags: needinfo?(hkoka)
Flags: needinfo?(hkoka) → needinfo?(francisco)
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.
Flags: needinfo?(wchen)
Flags: needinfo?(francisco)
Priority: -- → P2
Setting the blocker flag.
blocking-b2g: 2.5? → 2.5+
Whiteboard: [platform]
This isn't going to land in 44 (for 2.5).
[Blocking Requested - why for this release]:

Julien, 

Can you please tell if this needs to be a blocker? Its not landing in 44
blocking-b2g: 2.5+ → 2.5?
Flags: needinfo?(felash)
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).
Flags: needinfo?(felash)
But note this is really important for proper web component experience, not only for B2G but also for Desktop.
[Tracking Requested - why for this release]:

Thanks Julien. Will set the backlog flag so it will tracked post 2.5.
blocking-b2g: 2.5? → ---
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...
Flags: needinfo?(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)
Flags: needinfo?(overholt) → needinfo?(felash)
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.
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.
Flags: needinfo?(felash)
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.
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.
<style scoped> is gone.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → WORKSFORME
Resolution: WORKSFORME → WONTFIX
You need to log in before you can comment on or make changes to this bug.