RFC to allow applying classes to child components from the parent

[AlbertMarashi]

I was directed to post this to the RFCs, so I am reposting this from. sveltejs/svelte#4843

I am posting here to get thoughts or pros/cons about the various solutions

Feature request description.

I think Svelte is missing an important feature that other frameworks like Vue have. We need a way to easily apply CSS to a child component from the parent without having to use the verbose selector :global(childSelector) {} inside the CSS

We should be able to apply CSS via classes to child components from the parent element. This is a missing feature that should be in svelte.

Describe the solution you'd like

imagine <Link/> is a component that renders an <a> element and has some scripts for routing (eg: event.preventDefault()), and you would like to style that <a> element from the parent

Solution 1:

Add an attribute such as descendants or something to the <style> element to let svelte know that these styles should apply to child components too

<Link href="/about">About Us</Link>
<style descendants>
// notice the descendants attributes (similar to how Vue has scoped
a {
  color: red;
}
</style>

Solution 2:

Allow Child components to be given some sort of attribute that tells svelte to pass the scope to the child component, eg:

<Link:scoped/>
or
<Link scoped/>
<style>
a {
  color: red;
}
</style>

Solution 3:

Allow targeting of components within the parent CSS. eg:

<style>

Link {
  color: red;
}

// or
:component(Link) {
  color: red;
}

</style>

Solution 4:

Get svelte to inject the component's unique scope ID as a class, which would allow nesting in preprocessors

<style lang="stylus">

:scope() a {
   color: red;
}
// or
:scope() {
  a {
     color: red;
  }
}

</style>

Output::

.svelte-123 a {
  color: red;
}

Describe alternatives you've considered

I have considered taking the selector :global(childSelector){} but it is far too verbose, especially if you have something like a <Link> component for JavaScript routing, and it might be found in your nav, sidebar, content, headings, footer (with each instance styled differently)

Not to mention that this only works if you wrap the component in something (selector) otherwise it would apply the global everywhere, eg:

<div>
   <Link href="/about">About Us</Link>
</div>
<style>
	div :global(a) {
		color: red;
	}
</style>

I would like to do something like this:

<Link href="/about">About Us</Link>
<style descendants>
a {
 color: red;
}
</style>

How important is this feature to you?

This is such an important issue that has been raised a number of times and I am begging the svelte team to consider adding anything like this.

I am willing to contribute adding these features if supported

Additional context

This issue has been raised many times:

@nikku summed this up perfectly

• Passing class to components svelte#2870 (comment)

Related issues:

• RFC: Scoped Style Attribute svelte#901
• Support for components being able to impact css scope svelte#4661
• Passing CSS custom properties to components #13
• Styles get uncorrectly removed / how to pass down styles? svelte#4281
• Support classes on nested components svelte#2888
• Add the ability to add classes to slots svelte#4443
• Support global styles - Allow multiple top-level style tag declarations with different attributes svelte#2762
• Adding :scope pseudo-class support svelte#1450
• https://github.com/sveltejs/rfcs/blob/style-properties/text/0000-style-properties.md

Add any other context or screenshots about the feature request here.

[AlbertMarashi]

I will provide some thoughts as to why #13 is incomplete too. Firstly, I'd like to say that this is a useful feature that has been added, but doesn't address the fact of targeting sub-elements

<ChildComponent
  --border="3px solid blue"
  --borderRadius="10px"
  --placeholderColor="blue"
></ChildComponent>

Some issues with this:

1. It's verbose, if you have to do this outside of an {#each} for multiple items it's not great.
2. You can't target child elements of the child component effectively
3. Writing CSS will feel more natural to users and having CSS in HTML feels hacky

I totally understand the reason for using CSS variables, and I think the addition to svelte is great, but it doesn't address the other concerns

[AlbertMarashi]

I will also provide some thoughts as to why :global won't always work:
in here, if I want to target a specific element within a slot of a child component, it's not a great or easy thing to do when you're using a preprocessor

div :global(a){
   h1 {
      color: red;  // this will not work
   }
   h2 {
       color: blue; // this will not work
   }
}

instead you must do something like

div :global(a h1){
   color: red;
}

div :global(a h2){
   color: blue;
}

which I feel is verbose, and additionally, you must wrap your child component in an element in order to target it (div in this case)

[AlbertMarashi]

I know I am supposed to make an RFC using the template, but i'd like to get some more thoughts first

[hybridwebdev]

I fully agree. Having to write css inline on html is indeed hacky. Additionally it makes re-purposing/re-factoring/splitting up components far harder. As far as I'm concerned, any implementation that prevents writing natural css rules in the traditional method is flawed. Ideally, you should be able to write pure css in style tags in components, just like you can other frameworks(React or vue). This includes the ability for parent components to impact nested elements without the requirement of special declarations.

[slimboyfats]

I think that in case we are using descendants- style tag then we might also need to have the possibility to have a regular style-tag in the same components. Or am I overthinking?

< style >
a {
color: purple;
}
</style>

< style descendants >
a {
color: red;
}
</style>

[hybridwebdev]

No, i think that goes against what I am saying regarding requiring special syntax.

Why not just flat out the ability to just...style the descendants with normal css in a normal style tag.

Component

.some-comp
    .a-child

Style

   .some-comp { 
      style here...
   }
   .some-comp a-child {
      style here...
   }

I think that it is overthinking it by doing anything other than sticking to normal css hiearchy.

[slimboyfats]

Agree, sounds like the most natural way

[AlbertMarashi]

@hybridwebdev because you can't use preprocessing in that case.
@slimboyfats I would support having more than one style tag allowed in a component

[pngwn]

This need to be a pull request, there are clear instructions in the readme

[antony]

Why close this?

@hybridwebdev because a) this is the wrong place for a discussion/issue b) it's already been discussed to death in the Svelte repository.

There is clear need for a RFC on this, providing an exact implementation to be discussed and as such, that is the next step, not another endless discussion which doesn't go anywhere.

I've also deleted your comment as the remainder of it is the opposite of a constructive discussion.

[pngwn]

Thumbs down and sad face all you like. We have a clear RFC process and it needs to be followed. It isn’t difficult and it was clear from the start that this is what needed to happen.

[hybridwebdev]

Thumbs down and sad face all you like. We have a clear RFC process and it needs to be followed. It isn’t difficult and it was clear from the start that this is what needed to happen.

You seriously need to calm you jets and lose the attitude man. Community projects are just that...COMMUNITY. If you're going to treat contributors like this, you'll find yourself losing your community. That kinda toxic attitude is detrimental to your goal.

[antony]

@hybridwebdev you're talking to people who spend most of their free time helping others, contributing to community projects, and working with people to solve problems, out of the goodness of their hearts. Please remember that in future.

The RFC process is there to make everybody's life easier.

[hybridwebdev]

@hybridwebdev you're talking to people who spend most of their free time helping others, contributing to community projects, and working with people to solve problems, out of the goodness of their hearts. Please remember that in future.

The RFC process is there to make everybody's life easier.

Doesn't give you a right to be rude to people.

[pngwn]

We do value community contributions and I have invested a huge amount of effort and energy into that very same community.

That said managing a large open source project is difficult and we need to implement certain measures to make that more manageable. Having a structured RFC process is one of them. This is explained on the readme of this repo. I also explained that the author of the original issue needed to create a pull request in this repo, not create an issue.

I’m sorry it is upsetting to you that we have certain processes that have to be followed but that is how we handle RFCs. Further discussion can take place when this has a PR.