[css-shadow-parts] Expose parts programmatically

[JanMiksovsky]

It would be helpful for components with parts to expose those parts in some way that's programmatically inspectable.

For components with an open shadow root, someone could query inside the shadow for elements that have a part attribute, but this is not possible for components with closed shadow roots. To avoid leaking shadow elements, the proposed mechanism would return an array of string part names, not elements.

This would be akin to property reflection, and good for things like design/debugging/testing tools. E.g., it'd be nice if a tool could ask a DOM element what parts it has so that the tool can show the user a list of the parts available for styling.

Using the spec's example:

<template id="c-e-template">
  <span part="textspan">This text will be red</span>
</template>

The goal would be to allow something like:

const e = document.createElement('custom-element');
e.parts; // Returns the array ['textspan']

[FremyCompany]

That does seem useful indeed.

[tabatkins]

Yeah, this seems useful to expose; otherwise, the only place such information is exposed is in the (hopefully existent!) library docs.

It feels like something that DevTools would want to expose too; DevTools has magic powers and can get into closed shadow roots, but other tools offering similar behavior wont' have those powers and would want this information.

[fergald]

With exportparts, this could be an expensive operation, you have to descend into children and apply the exportparts maps at each level. Currently we don't ever assemble all of the parts of a given component like this but it does seem like something devtools should provide at least.

Are there other useful things that external dev tools cannot do with closed custom elements or shadow roots that built-in dev tools can? By useful I guess I mean things like API discovery, not things like digging around in implementation details.

[tabatkins]

That's a reasonable concern; marking it as a function rather than an attribute is probably appropriate, then.

This recursion is no more expensive than many other recursive operations, so we don't need to do anything more special than that. But having it recurse does violate the usual expectation of attributes=cheap.