Re: [w3c/webcomponents] Provide a lightweight mechanism to add styles to a custom element (#468)

@rakina Many thanks for that explainer! Such summaries make it much easier to see where things stand on long-lived issues like this.

I have some questions about whether this default style mechanism could be used to style custom elements defined by other people. We believe people will often want to take a component written by someone else and style it to match the aesthetics of their app. It would be advantageous if the default styles proposal could accommodate that situation.


1. The proposed rules dictate that "The default styles will be treated as if they are the first stylesheets in the custom element's shadow root's stylesheets, if exists". That definition may limit the ability to customize a component that already has styles.

Consider someone writing a component, and someone else trying to customize it.

```html
<!-- These artifacts are written by the component author. -->
<template id="baseTemplate">
  <style>
    :host {
      color: red;
    }
  </style>
</template>
<script>
  class BaseElement extends HTMLElement {
    constructor() {
      // Create shadow root, clone above template into it.
    }
  };
  customElements.define('base-element', BaseElement);
</script>

<!-- Written by a user of the component who wants to make it blue. -->
<style id="customStyles">
  * {
    color: blue;
  }
</style>
<script>
  const customSheet = document.querySelector('#customStyles').sheet;
  customElements.define('custom-element', BaseElement, { styles: [customSheet] });
</script>
```

As I read this, the default styles defined for `custom-element` will _not_ make the text blue as desired. The default styles are treated as if they appear first, putting the rule to make the text blue _before_ the rule to make the text red.

The "green" example in the explainer touches on this point. While that example is helpful in understanding ramifications of the feature, I don't think that situation represents a desirable outcome. Generally, I think it's going to be very unusual to attach a shadow root to an element you don't define.

I think it'll be much more common to want the default styles to override the styling inside a shadow root, instead of the other way around. That is, the user doing the customizing would prefer to have the default styles effectively come _last_, after the contents of the shadow root.


2. Can pseudo-elements be used in rules that match the element?

I would imagine that rules like `*::selection` would be helpful, but didn't see them mentioned. It would also open up the possibility of the next point...


3. Assuming the [CSS Shadow Parts](https://drafts.csswg.org/css-shadow-parts/) proposal were to proceed along its current lines, would a `*::part` selector in the default style sheet match a part in the element's shadow root?

It would be helpful if the answer were "yes". The point of `::part` is to let a component expose something it wants to be styleable from the outside, so nothing about the shadow's content is leaked (as would be the case with complex selectors like `* > div`).


Generally speaking, we think it'd be very nice if someone could customize a component using this default styles mechanism. In our experience, almost all web components adopted from elsewhere need some degree of customization. The lightweight design of the feature is proportional to the lightweight level of knowledge/experience someone might expect to need to simply apply custom styling to a component they acquired from another party.

We think that the intersection of default styles and `::part` is particularly interesting. The `::part` proposal will definitely help with customization, but requiring styles via separate CSS stylesheets increases the cost of working with a component. E.g., a company obtains a `generic-carousel` component from elsewhere, and creates `customCarousel.css` to customize it. They now have two artifacts (the component definition and the custom stylesheet) that everyone at the company needs to remember to use together.

We think it would be easier if such a company could create their own custom element definition using this default styles feature, bake in rules that customize the element and its constitutent parts, to end up with a company-specific, customized `branded-carousel` custom element they can easily reference by a tag name.


-- 
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/468#issuecomment-430336471