# General concepts
## Component styling
Out of the box, these components are completely unstyled. This has some big advantages: you're free to make them look however you want, without having to fight against any pre-existing styles that don't fit in with the look and feel of your site. Instead of being constrained by an existing design system like Material Design or Carbon Components, you can fully customize your components' appearance--but letting the library take care of implementing all the keyboard and mouse interactions, accessibility features, and so on.
The flipside of unstyled components, however, is that you need to, well, style them. There are a number of ways of doing this.
### Styling children: slot props
You can style the descendants of components from this library with the help of slot props:
```svelte
(plan = e.detail)}>
PlanStartupBusinessEnterprise
```
### Styling the components themselves: `class` and `style`
Slot props can be used to style any descendent components, but they cannot be used to style the same component that defines them. To work around this, any component that defines slot props will also optionally accept a **function** for its `class` and/or `style` props. These functions will be **called with the slot props as an argument**:
```svelte
(plan = e.detail)}>
Plan (checked ? "checked" : undefined)}
>
Startup (checked ? "checked" : undefined)}
>
Business (checked ? "checked" : undefined)}
>
Enterprise
```
See the individual component documentation to learn about the slot props for each component.
You may also pass a string for `class` or `style`, or omit them entirely, of course.
What follows below is some guidance on the different ways to use the `class` and `style` props to style your components.
#### Using Svelte's `
```
This works great for styling HTML elements. However, it (unfortunately) does **not** work for styling _components_. If you try to create the same example without the ``s, it won't work:
```svelte
(plan = e.detail)}>
Plan (checked ? "checked" : "")}
>
Startup
(checked ? "checked" : "")}
>
Business
(checked ? "checked" : "")}
>
Enterprise
```
(Note that we also can no longer use the `class:checked` shorthand on a component)
Why doesn't this work? When Svelte compiles our component, it adds in a special unique class to the CSS rules and to the HTML elements rendered by this component that are affected. But it does _not_ add this special class to any child _components_. The result is that the `.checked` CSS rule will be generated with a second class that the `` components do not have, and it will not match.
Unfortunately there is no way in Svelte right now to pass this special class down to the `` components, and the framework does not have a good solution in general for this. Hopefully one day the Svelte maintainers will add some way of solving this problem. Until then, you can still style your components using one of the approaches below.
#### The `:global()` modifier
The `:global()` modifier opts your rule out of the default component style scoping. CSS rules inside `:global()` are treated as "normal" CSS, so the following will work:
```svelte
(plan = e.detail)}>
Plan (checked ? "checked" : "")}
>
Startup
(checked ? "checked" : "")}
>
Business
(checked ? "checked" : "")}
>
Enterprise
```
However, global CSS has one critical downside: it's global! The `.checked` rule above will now apply to _any_ `.checked` CSS class in your application, even if it's in other components. In a larger application, this can get difficult to maintain.
You can scope this more narrowly if you have a wrapper element:
```svelte
```
In this case, this works perfectly.
When using this scoped `* > :global()` approach, keep in mind these principles:
- Your Headless UI components must be contained inside some element **that is rendered by your component**, like the wrapper `
` above. You need an element for the Svelte scoped class to be attached to.
- Your rule will be scoped to your component **and any descendant**. In the example above this is not a problem, since the component has no ``s. But if your component _does_ have ``s, you will still need to be careful for collisions.
- This rule won't work properly inside a portal, which means that it won't work properly for a `