Re: ::Parts of cats and hats everywhere, slashed by shadow


Daniel wrote:

> Yesterday a group of folks from this thread convened for a face-to-face
> meeting.

Was this in SF? I would have happily skipped my one-hour-each-way
commute on 280 to attend.

> A long time ago in a galaxy far away, there was a feeling we should
> security-encapsulate Shadow DOM

(This is Type 4 encapsulation in Maciej's typology.)

> it was a noble pursuit, a courageous endeavor. After a few cycles with
> the specs it became imminently clear that security-encapsulation of
> Shadow DOM is fraught with significant problems, and the added
> constraints only made possible a small number of all total use-cases.

I agree that we shouldn't be aiming for Type 4 encapsulation in the
component model.

> As a result, the decision was made to instead provide a flavor of
> encapsulation that shielded non-explicit Shadow DOM access and style
> overwriting.

(This is Type 1 encapsulation in Maciej's typology.)

You say "the decision was made," but I don't know what that means. AFAIK
the participants in the relevant public-webapps threads did not in fact
come to agreement on this issue, and I don't think the WebApps WG has
ever officially resolved on this. (If you want to debate this point,
let's do so over on public-webapps.)

I don't think we should throw out the Type 2 baby with the Type 4
bathwater. My impression from the last few days of www-style and
public-webapps is that folks from multiple organizations agree that Type
1 encapsulation is insufficient and that we should strive for Type 2
encapsulation in the component model.

> Why talk about the JavaScript interface portion of Shadow DOM in a
> debate over a style issue? Because new web platform technologies that
> introduce APIs across layers of the stack are usually at their best
> when they are symmetrical, predictable, and familiar.
> Assessment: [the ^/^^] proposal is[…] symmetrical to the JS DOM
> encapsulation paradigm.

Putting aside for the moment the continuing disagreement about what the
JS-side encapsulation should be like, ^/^^ is *not* symmetrical with the
existing JS-side feature set.

Component authors have the ability to explicitly expose JS API to
developers using their component, and *additionally* the shadowRoot
property provides an escape hatch if the explicitly exposed API is
inadequate. As you said:

> An important allowance was the ability for component consumers to
> explicitly access the Shadow DOM via the shadowRoot property. This
> provided a way for developers to knowingly, explicitly reach into a
> component and manipulate its DOM[…]

But ^/^^ are only equivalent to the shadowRoot escape hatch—there's no
provision for the component author to explicitly choose specific parts
of the Shadow DOM to be exposed.


Received on Friday, 7 February 2014 20:44:31 UTC