Re: Shadow DOM: Hat and Cat -- if that's your real name.

Hi,

Sylvain wrote:

> Not only am I willing to believe you, when it comes to Shadow DOM I
> *want* to[…] I actually believe in the damn thing and, if you go back,
> did so from day one.

Right. I think (or at least, I hope) that this is the case all around.
That's precisely *why* people are so concerned that this might get
shipped prematurely! It's so, so important to the Web that we get this
right. It's OK if that takes time.

> But I also believe this is a fundamental enough change for the
> platform that some level of cross-browser consensus is far more
> important to success than it is for, say, will-change.

Indeed.

Tab wrote:

> In particular, any alternate suggestions in this thread are based not
> on any experience at all, but just a very short period of thought
> without much experience of the feature as a whole.

What was that about the principle of charity? It should be clear to
everyone at this point that many browser engineers from all of the
relevant engines have spent a tremendous amount of time over the years
thinking about, designing, implementing, and yes, even shipping
components features. IE's HTA, Hyatt's XBL, etc., etc.

Concretly, the current issue—what level of encapsulation should Shadow
DOM have by default—has come up several times in email and at face to
face meetings over the years. For example, here's an email from Maciej
on this topic from June 2011:

http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html

In this email he defined several forms of encapsulation and identified
one of them (numbered 2 in his email) as fundamental to a successful
component model:

> 2) Encapsulation against deliberate access - no API is provided which
> lets code outside the component poke at the shadow DOM. Only internals
> that the component chooses to expose are exposed.

He went on to outline why this is so important:

> I believe type 2 encapsulation is important, because it allows
> components to be more maintainable, reusable and robust. Type 1
> encapsulation keeps components from breaking the containing page
> accidentally, and can keep the containing page from breaking the
> component. If the shadow DOM is exposed, then you have the following
> risks:
>
> (1) A page using the component starts poking at the shadow DOM because
>     it can - perhaps in a rarely used code path.
> (2) The component is updated, unaware that the page is poking at its
>     guts.
> (3) Page adopts new version of component.
> (4) Page breaks.
> (5) Page author blames component author or rolls back to old version.
>
> This is not good. Information hiding and hiding of implementation
> details are key aspects of encapsulation, and are good software
> engineering practice. Dmitri has argued that pages today do a version
> of components with no encapsulation whatsoever, because many are
> written by monolithic teams that control the whole stack. This does
> not strike me as a good argument. Encapsulation can help teams
> maintain internal interfaces as they grow, and can improve reusability
> of components to the point where maybe sites aren't quite so
> monolithically developed.
>
> Furthermore, consider what has happened with JavaScript. While the DOM
> has no good mechanism for encapsulation, JavaScript offers a choice.
> Object properties are not very encapsulated at all, by default anyone
> can read or write. But local variables in a closure are fully
> encapsulated. It's more and more consider a good practice in
> JavaScript to build objects based on closures to hide implementation
> details. This is the case even though the closure approach is more
> awkward to code, and may hurt performance. For ECMAScript Harmony, a
> form of object that provides true encapsulation is being considered.
>
> I don't want us to make the same mistake with DOM components that in
> retrospect I think was made with JavaScript objects. Let's provide
> good encapsulation out of the gate.
>
> And it's important to keep in mind here that this form of
> encapsulation is *not* meant as a security measure; it is meant as a
> technique for robustness and good software engineering.

This argument is as true today as it was three years ago.


Thanks,
Ted

Received on Thursday, 6 February 2014 20:28:45 UTC