Goals for Shadow DOM review

(This email summarizes some offline conversation I had with Alex, so we can get more people involved. I'm also CCing people who I know have an interest in this sort of thing.)

It seems to me that the technical review of shadow DOM is already well underway via implementers and implementer feedback. This has produced a number of good results, e.g. Anne's attempts to formalize the "monkey patching" they do of DOM algorithms. As such technical review of the spec is probably well taken care of already.

However, there's a lot of interesting stuff the TAG could advise, around how well the shadow DOM fits into the platform, the platform's future, and our general interest in a layering strategy. For example, can shadow DOM be used to explain existing elements, like <video> or <input type="range">, in terms of a lower-level primitive?

As of now, it seems like it cannot, for two reasons:

1. Native elements have extra capabilities which are not granted by shadow DOM, or by custom elements. For example, they can participate in form submission.
2. The shadow tree of native elements is entirely encapsulated; you cannot access it via JavaScript, or style it via CSS (even with the-selectors-formerly-known-as-cat-and-hat). This is a hard security boundary---much harder than the permeable-via-esoteric-tricks encapsulation boundary being suggested by Apple on public-webapps.

#1 suggests it would be helpful to enumerate what platform capabilities are still missing from the web components work. I know Arv has been doing some of this, filing bugs on the spec related to missing capabilities.

#2 is interesting. It has two possible outcomes. On the one hand, this could tie back to the desires for a strong encapsulation version of shadow DOM, that completely allows the component's author to hide all implementation details. On the other hand, it could lead to attempting to loosen the boundary, so that authors *could* use standard shadow DOM mechanisms to style <select> or <video> elements. This would be a large project, since we'd want to be sure there is a standard set of accessible structures across user agents. It may not be possible. But it would help solve an age-old problem of how to style the darn <select> element.

Finally, another interesting aspect of how shadow DOM could help explain the platform is in terms of CSS generated content. Could it give some real life structure to ::before, ::after, etc.? Apparently this is tricky because implementations typically make these pseudo-elements more lightweight than a typical shadow element would be. But it is worth exploring whether this is possible.

It would be cool to get the TAG's perspective on these larger issues.

Received on Thursday, 20 February 2014 18:53:06 UTC