You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's a general assertion that I want to vet: Svelte introduces CSS cascading behaviors that unintentionally breaks normal conventions with global scope.
Maybe a second assertion to question: the :global() modifier is doing nothing to fix that.
I put this in the forum, but figured it might be important enough for a ticket.
--
I just ran into some really rough edge use-cases around the :global() modifier. The kind of thing that will introduce a lot of unexpected results for people scratching their heads (as I did mine for a bit).
Scenario
I often apply top level html classes for different global states. Examples:
<html class="auth some-menu-open">...
vs.
<html class="no-auth [no menu class needed when closed]">...
Etc.
This sort of methodology sandboxes the whole (freakin') environment in an easily encapsulated way to target differences application wide without having to apply state to each (flippin') component/module/element. Very handy use case for what everyone complains about with CSS—global leakage. In this case, it's a boon. (Think of it as store for CSS.)
NOTE: I'm a huge believer in encapsulation with components and / or modules of the Internetz, so this definitely is something I only reach for in certain scenarios. But they are warranted scenarios.
However, when trying to apply something global from a component, a.k.a.
:global(html.no-auth) .whatever { ... }
It won't always cascade/override, because Svelte is applying it's own hidden/non-obvious/obtuse classes/ids for scoping:
Expected behavior:
Should override my scoped/component changes:
:global(html.no-auth) .whatever
Actual behavior:
In some cases, the component's scoped .whatever.svelte is actually still applied. This is especially true if CSS is nested, i.e.:
li.svelte-1sgnya4 a.svelte-1sgnya4 { ... }
^^^ That's never going to be easy to override.
Idea?
Should :global()only apply to that which it surrounds? That flies deftly in the face of this proposal: #901
I brought it up prior: #1080 And it might be time to reopen. Cascading styles in a modular/component focused environment are notoriously difficult to grapple with. Here's an edge case that shows one of those problems.
Is it worth taking this up as a large topic, i.e., is the :global() and scoped approach the right one? What can be fixed so global scoped cascading actually works as expected instead of weird edge cases?
I don't have a strict proposal, though I have ruminations which need more time to gel.
The text was updated successfully, but these errors were encountered:
Update: someone in the forums made me think a little harder about this, and I came up with an actually not too-far-fetched example:
...on the surface it's as easy as using a store variable [and passing it down the line]...but in real world CSS behavior, it's expected to be able to use [this sort of behavior]...if I had some app that changed the look of EVERY <h1> element everywhere based on state...that kind of thing would be HORRIBLE to handle by passing state/vars down the line...
There are already some other open issues and making sure that we don't change the relative specificities of scoped styles when we attach the scoping classes - but I don't see the mechanism used for style scoping changing any time soon, and any changes to CSS specificity relative to styles defined outside of Svelte components that this causes are just going to be something we have to live with.
Here's a general assertion that I want to vet: Svelte introduces CSS cascading behaviors that unintentionally breaks normal conventions with global scope.
Maybe a second assertion to question: the
:global()
modifier is doing nothing to fix that.I put this in the forum, but figured it might be important enough for a ticket.
--
I just ran into some really rough edge use-cases around the
:global()
modifier. The kind of thing that will introduce a lot of unexpected results for people scratching their heads (as I did mine for a bit).Scenario
I often apply top level html classes for different global states. Examples:
vs.
Etc.
This sort of methodology sandboxes the whole (freakin') environment in an easily encapsulated way to target differences application wide without having to apply state to each (flippin') component/module/element. Very handy use case for what everyone complains about with CSS—global leakage. In this case, it's a boon. (Think of it as store for CSS.)
NOTE: I'm a huge believer in encapsulation with components and / or modules of the Internetz, so this definitely is something I only reach for in certain scenarios. But they are warranted scenarios.
However, when trying to apply something global from a component, a.k.a.
It won't always cascade/override, because Svelte is applying it's own hidden/non-obvious/obtuse classes/ids for scoping:
Expected behavior:
Should override my scoped/component changes:
Actual behavior:
In some cases, the component's scoped .whatever.svelte is actually still applied. This is especially true if CSS is nested, i.e.:
^^^ That's never going to be easy to override.
Idea?
Should
:global()
only apply to that which it surrounds? That flies deftly in the face of this proposal: #901I brought it up prior: #1080 And it might be time to reopen. Cascading styles in a modular/component focused environment are notoriously difficult to grapple with. Here's an edge case that shows one of those problems.
Is it worth taking this up as a large topic, i.e., is the
:global()
and scoped approach the right one? What can be fixed so global scoped cascading actually works as expected instead of weird edge cases?I don't have a strict proposal, though I have ruminations which need more time to gel.
The text was updated successfully, but these errors were encountered: