[css-shadow-parts] Web Component default *exportparts=*

[frivoal]

(Split from issue #3467, reported by @stefsullrew)

When building a custom web component via composition not having to explicitly specify exportparts= would improve the experience.

The example below presents a possible solution where, at component creation, exportparts= is defined.

class BarElement extends HTMLElement {
  constructor() {
    super();
    
    const shadowRoot = this.attachShadow({mode: 'closed'});
    
    shadowRoot.innerHTML = `
        <h1 part="header">Headline</h1>
        <p part="metadata">Posted on: 2019-01-10</p>
        <div part="content">...</div>
    `;

    if (!this.hasAttribute('exportparts'))
        this.setAttribute('exportparts', 'header, metadata, content');
  }
}

customElements.define('bar-element', BarElement);

<x-foo>
    <!-- iteration of bar-elements -->
    <!-- since no manual "exportparts=" was specified on each instance
         the defaults are exported -->
    <bar-element></bar-element>
    <bar-element></bar-element>
    ...
</x-foot>

x-foo::part(header) {
    color: green;
}

[fergald]

So you'd prefer a default where if it's not specified, all parts are exported under their original name and to prevent exporting you'd have to explicitly do e.g.

<custom-foo exportparts=""></custom-foo>

The counter proposal to that would be to implement wildcard forwarding so that it is at least trivial to export everything with e.g.

<custom-foo exportparts="*"></custom-foo>

I'm not sure how decide which of all or nothing should be the default. I don't recall any previous debate on it. @tabatkins do you remember anything?

[fredboyle]

@fergald Not so much to export everything but define a list of parts that would always be exported unless overridden.

So in the example above (initial post) if we wanted to always export the header part if no exportparts= was provided, we could do that. This would avoid consuming developers from having to always specify it and simply use the component with no exportparts= attribute. Does that make sense?

This facilitates the composition scenario and avoids deeply nested exportparts= chains. We want to provide ease of use and remain flexible in the ability to customize but with some guardrails in place.

Hope that helps.