Skip to content

How to fix Global vs Scoped CSS cascading issues. #1536

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
arxpoetica opened this issue Jun 10, 2018 · 3 comments
Closed

How to fix Global vs Scoped CSS cascading issues. #1536

arxpoetica opened this issue Jun 10, 2018 · 3 comments
Labels
awaiting submitter needs a reproduction, or clarification

Comments

@arxpoetica
Copy link
Member

arxpoetica commented Jun 10, 2018

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.

@arxpoetica
Copy link
Member Author

arxpoetica commented Jun 10, 2018

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...

@Conduitry Conduitry added the awaiting submitter needs a reproduction, or clarification label Aug 3, 2019
@antony
Copy link
Member

antony commented Apr 9, 2020

@arxpoetica any further thoughts on this or can we close it?

@Conduitry
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting submitter needs a reproduction, or clarification
Projects
None yet
Development

No branches or pull requests

3 participants