Re: [w3c/webcomponents] Theming options for shadow roots (#864)

This is a list of use cases I’ve been going back to over the years, whenever we’ve been thinking about what our styling/theming solutions should support in Vaadin. The use cases try to follow the process which a designer goes through when working on theming an application, from the more generic use cases to the specific ones.

I’m marking them with global/local to indicate where these styling customization should be applicable. Global means that the application developer can apply the styles to a component inside any shadow root they need. Local means that the styling only needs to be applicable in a single style scope.

---

### 1. Configure the default appearance of all components uniformly (global)

Usually the first step when adapting an existing style to a custom brand. Examples what is usually done here:

- **Customize the color palette**
  This should be easily doable with custom properties. I don’t see big problems here.
  The same applies to some other theming aspects, like spacing. Basically anything that you usually control with one CSS property.

- **Adjust typography**
  Choose at least the font family, size, weight, and line-height for body text, headings, field labels, buttons, etc.
  Custom properties work to a degree, but creating a reusable “style” that includes size, weight, line-height, letter-spacing, etc. is a little complicated (should I create custom properties for all possible font properties per heading level?). In hindsight, the `@apply` mixins were a nice solution to this, IMO.
  There’s some overlap with this and component-specific styles – should all text types (body, headings, labels, button text) be components, or general purpose, “portable” CSS?

**Advanced use case**: be able to override certain styles for all component with a specific style name.
For example, create a “small” variant of all components (the same use case @web-padawan demonstated)


### 2. Configure the default appearance of a single component (global)

After the designer has configured the global theming as far as they can, where all changes still apply to all components, they start working on individual components. For example, let’s say that buttons have a different border radius than any other component (pill shape) and a custom gradient background. The background gradient reacts to the different states of the button (hover, active, disabled). The designer wants those changes to apply for all buttons across the application.

**Advanced use case**: take the styles from a different theme for some components.
For example, there is an existing theme that already defines the desired styling, let’s say the floating labels from Material Design, and the designer would like to use those. Copy-pasting them is an option, sure, but it would be nicer to somehow import those styles instead. Might help to think of a “style module” here.


### 3. Configure the appearance of a single component variation (global)

After adjusting the default appearance of buttons, the designer wants to adjust the primary button styles. The button component has a built-in style for that (e.g. `<vaadin-button theme="primary">`) and they want to have a different gradient background and font color for that variant (including different states).


### 4. Create a single component instance variation (local)

Now the designer moves to do any one-off, view-specific adjustments needed. The styles they need for this case are not something would make sense to define as a global variant.


### 5. Create a new uniform variation or all components to work along all the other styles (global/local)

The designer wants to create a scoped context where all components adapt to a certain variation. This is close to the first advanced use case (”small variant”). Instead of having an explicit variant for a component (e.g. `<vaadin-button theme="small">`), all components placed inside this context adapt automatically. An example would be an inverted (dark) color palette for a sidebar/nav in an app.

This could be a one-off situation (local), or something the designer wishes to utilize in multiple places in the app (global).


### 6. Style a completely new component (global)

There is an application-specific component, a switch/toggle with built-in customizable labels for on/off for example, that should adapt to the theme, including to all of the global variants (e.g. small). The designer also wants to define custom variants just for this component, “hide-labels” for example.

---

I can try to provide more context or examples (mockups) if any of this is unclear.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/864#issuecomment-591848387