Shadow Dom Movement? about extensible-web-report-card

[travisleithead]

We currently say it is "disruptive in class":

Shadow DOM

Doesn't actually explain the platform's shadow DOM due to lack of encapsulation and inability to negotiate layout between the component and its surroundings -- similar issue to <iframe seamless> and cross-origin content.

Conflates selector matching, CSS inheritance, and event retargeting isolation boundaries into a single primitive

Need e.g. custom pseudo-elements as a way of exposing standardized styling hooks, both for developer-created controls and for standard controls like <details> or <input type="date">.

---

So in paragraph 1:

• lack of encapsulation - the spec now has open and closed versions of shadow doms. Closed Shadow DOMs are acknowledged to not be fully isolated, as type-system hijacking can lead to exposure into the closed tree. It's a step in the right direction (like having closures in JavaScript). Fully isolated components are a v2 conceptual idea (see proposals here and here).
• inability to negotiate layout - I'm not totally clear on what this implies. Some guesses: the component can't discover it's size, or impact its size with respect to it's host; the component doesn't have the right styling hooks...

Paragraph 2:

• conflation - I think to a degree this is still a problem. The group has discussed breaking out the event retargeting solution into a separate configurable primitive. Inheritance is being discussed (see Issue 314. Selector matching has been a problem in the past, though removal of the uber-powerful >>> combinator has been well-received. Now you have very limited access by default, and the expectation of using CSS custom properties (variables) to style the component has been successfully applied by the likes of Angular and Polymer frameworks.

Paragraph 3:

• custom pseudo-elements - Tab is arguing for a new CSS concept @apply to largely handle this use case, but not all are convinced it will fit every need. I think it helps a lot and gives a lot of flexibility for styling.
• closing the gap for native controls - Yep, still something that should be explained. I suppose implementations could expose their configurability as custom properties, but in the past they've only done so with custom pseudos. So there's a gap there.

In addition to the above, if a generic pseudo element is exposed, component authors will need a way of whitelisting or blacklisting the properties they want to apply, in order to prevent component users from potentially destabilizing their component with weird display: table or similar hijacks.

[bkardell]

@travisleithead important points in the above that I was saying to @torgo seem like worth noting as "shows improvement" or something (however you want to track movement given that we have this report card metaphor)

p1 - bullet 1. there's much improvement in terms of encapsulation. bullet 2. houdini may solve well enough
p2 - the move to named slots instead of selector-based pull in through content and removal of piercing combinators/settling on how specificity works all seem like significant improvements -- interestingly I think some of them only could have been figured out this well by failed experimentation because bits of it that seem kind of obvious in retrospect actually seemed kind of appropriate at the time until we had some time/users to experiment.
p3. If configurability through custom properties works out (I think it will, it's one of the reasons we worked on custom properties that way but I reserve the right still be to be wrong once we try it) it could be used to explain some things previously unexplainable or problematic (like potentially properties of a <select> which obviously have important different OS displays/interaction modes). That much seems like improvement too.

[torgo]

Discussed in TAG call 21 October. We tentatively agreed to move shadow dom into "plays well with others."

[bkardell]

woot \o/

[torgo]

possible caveat that we encourage further development of the API

[torgo]

suggest Travis draft some replacement text as a pull request

[travisleithead]

timed out!

---

The TAG has decided to no longer maintain the extensible web report card. Instead of addressing these issues in this document, major issues should be re-raised on the http://github.com/w3ctag/design-reviews repo; other feedback may be added to the individual (original) specs if needed.

Apologies for the delay. Thanks for flying TAG.