Styles still applied to main DOM when using Shadow DOM.

[SimmeNilsson]

Reduced Test Case

https://codepen.io/arshaw/pen/zYLJeRx?editors=0010

Do you understand that if a reduced test case is not provided, we will intentionally delay triaging of your ticket?

• I understand

Which connector are you using (React/Angular/etc)?

No connector (vanilla JS)

Bug Description

Related to #7118

When using Shadow DOM, the styles are added to the Shadow DOM.
However, they are also still added as style elements to head of main page, which can be seen when inspecting the DOM.

Also, if the style elements then are removed from the main page manually, some parts of the styling, like the grid lines, go missing.
(The style element that starts with :root{... )
So seems to be things in the main DOM required even though the Shadow DOM seems to contain the same part.

Before removal

After removal

[arshaw]

Without a doubt you've identified some strange behavior. Let me try to explain what was intentional and what wasn't...

For normal DOM usage (not shadow DOM), styles should be attached to the document ASAP to avoid a FOUC. If we wait until a Calendar is initialized, it's too late. That's why we attach it globally as soon as the FullCalendar library executes. It's not possible to wait until a Calendar is initialized and then conditionally include the styles based on whether it's inside a shadow DOM or not.

The reason the styling WITHIN a shadow DOM breaks when the document-level styles are removed is that the shadow DOM styles rely on outer --css-variables as well as @font-face (which can't be injected within a shadow DOM). I didn't realized this reliance until you pointed it out, but it just reaffirms my decision to have the styles always exist on the document-level.

At some point we'll stop using css variables, and we'll move away from font-face for icons. We'll reevaluate then.

Is this causing you any bugs?

[SimmeNilsson]

We have a somewhat big microfrontend where fullcalendar might come from multiple projects and loaded into the same page, even different major versions.
Some CSS collisions were detected and we opted for Shadow DOM as a way to separate the different fullcalendar css:es.
It was a smaller effort than synching and centrally hosting fullcalendar. But seems we might have to opt for that instead if the separation can't be guaranteed.

[EliezerB123]

Is this causing you any bugs?

@arshaw Not exactly a bug, but there are all these CSS styles trampling all over every single element across the entire app in Chrome Dev Tools because they're not scoped to a full-calendar element. Developers are having a hard time finding our own CSS variables because of this. (It's driving us crazy that they aren't scoped to .fc or something similar. Is there any configuration or work-around we can set to change them to be scoped to .fc instead of :root? We can't even import a custom, modified CSS file, because FullCalendar injects the styles directly via JS.)

[EliezerB123]

Without a doubt you've identified some strange behavior. Let me try to explain what was intentional and what wasn't...

For normal DOM usage (not shadow DOM), styles should be attached to the document ASAP to avoid a FOUC. If we wait until a Calendar is initialized, it's too late. That's why we attach it globally as soon as the FullCalendar library executes. It's not possible to wait until a Calendar is initialized and then conditionally include the styles based on whether it's inside a shadow DOM or not.

The reason the styling WITHIN a shadow DOM breaks when the document-level styles are removed is that the shadow DOM styles rely on outer --css-variables as well as @font-face (which can't be injected within a shadow DOM). I didn't realized this reliance until you pointed it out, but it just reaffirms my decision to have the styles always exist on the document-level.

At some point we'll stop using css variables, and we'll move away from font-face for icons. We'll reevaluate then.

Is this causing you any bugs?

@arshaw ....Is there any way to remove the CSS? Honestly, we'd much rather have a FOUC (On our side we can opacity:0; max-height:100px; overflow:hidden; or display:none; it until it finishes loading.) (or, better yet, scope the CSS variables to the class .fc instead of :root) than have all of these :root variables cluttering every single div in DEV TOOLS because ONE component on ONE page has a calendar.

[JuratYusup]

I have the same problem, in microfrontend

[hughbris]

My front end chops are lacking in the modern era, but after two days futzing with this I have to ask: is this related to #7720?