Re: Goals for Shadow DOM review

On Thu, Feb 20, 2014 at 10:52 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> (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.
>

Elliott had done some explorations on how that could be done a while back.
Not sure if he still have all that data paged in.

:DG<