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

Hi,

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.


Thanks,
Ted

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