Re: Encapsulation and defaulting to open vs closed (was Re: Shadow DOM Encapsulation)

On Feb 6, 2014, at 5:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Thu, Feb 6, 2014 at 4:22 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> That seems clearly false. If shadow DOM is subject to Type 2 encapsulation by default, the author can always opt out to Type 1. Even if we don't provide a feature for it, component authors can always do something to expose the shadow DOM themselves. However, there is no way to build Type 2 on top of Type 1. That is why I think defaulting to Type 1 and providing only Type 1 is a mistake. We can't have any experiments for whether Type 2 would be sufficiently useful and beneficial because you can't do it.
>> 
>> This actually makes Type 2 the more fundamental primitive! You can't build it on top of Type 1. Am I allowed to cite http://extensiblewebmanifesto.org at this point?
> 
> Of course it's possible to build Type 2 on top of Type 1 - just delete
> or override the .shadowRoot accessor from the element.

You can't override it because it's readonly. To delete it, you'd have to delete from the prototype. But that's not a great idea because it is on the Element prototype. So you wouldn't be able to share public and private components on the same page.

Even if you could delete it, you'd still have ^ and ^^ to contend with, if those go through - you can use querySelector() on those to break any DOM encapsulation. In fact, once people get used to slinging around ^ and ^^ it will be hard to defend against them. (Note also that part selectors can't be built on top of ^/^^ but there are forms of part selectors that allow the equivalent of ^ to be built on top.) Note: the more different ways you expose the shadow root the harder it becomes to get Type 2 encapsulation, even if each has its own individual way to opt out.

> (Just to head off a potential objection - yes, other script can
> preempt you on this and retain access.  Just like I argued before, and
> you've acknowledged, solving that is an orthogonal problem.)

It's a problem that is solvable in a way that falls short of full isolation but is still useful. But I'm not confident that this solution can be bolted on later without the specs even acknowledging any kind of private mode at the moment. I'd strongly prefer if we specify both modes and then make a thoughtful decision about which should be default (instead of spec editors just doing what they want and then making it a fait accompli by shipping it).

Regards,
Maciej

Received on Friday, 7 February 2014 02:13:21 UTC