DEV Community

Discussion on: Beyond the polyfills: how Web Components affect us today?

Collapse
 
jamesernator profile image
James Browning • Edited

As spec-ed :host-context isn't super useful anyway as you can only select "some ancestor" rather than "some parent" or even more complex relations. Maybe once :has lands in browsers we'll be able to do :host-context(some-parent-element-type:has(> :host)) in which case I'd be more likely to care about the feature again.

For leaking styles in, in a lot of cases ::part is still too cumbersome if you want to expose many elements (although it's still great as custom-pseudo-elements). In a lot of cases I'd just like to defer styling of elements to whatever the outer tree is styling them as. Perhaps with something like:

<style>
  button {
    color: red;
  }
</style>

<my-element>
  <!--shadowroot-->
    <style>
      button {
        /* Not to be mistaken for all: inherit, this just allows this element to
            match element name selectors that are outside of the shadow
            tree, I haven't thought through the details of this idea 
            thoroughly though like how it might interact with nested trees
        */
        inherit-from-outer-tree: element-name pseudo-classes;
      }
    </style>
    <!-- is red because it matches the outer stylesheet's selector -->
    <button>Hello world</button>
  <!--/shadowroot-->
</my-element>
Collapse
 
webpadawan profile image
Serhii Kulykov • Edited

My gut feeling is that overusing ::part could be a smell of incorrect API design of the component (so that it could be split further into a number smaller components, etc).

At Vaadin, we have the workaround for writing CSS using [part] attribute, and then injecting those <style> tags into shadow trees. That's convenient in most of cases, but still not ideal, and developers need some time to learn that model.