Re: [whatwg/dom] Declarative Shadow DOM (#831)

Ok, there are two concerns being discussed here, on this thread and in [issue 871](https://github.com/w3c/webcomponents/issues/871). Since they're connected issues, I'm going to try to bring the discussion back to here for most of it.

The two issues as I see them are:

1. The `.content` accessor on `<template>` can be used to break encapsulation and cause problems. Scripts and MutationObservers can be used to grab references to child nodes of the declarative `<template>`, among other things, while parsing is taking place.

Solution: for `<template shadowroot>` declarative templates, change the `.content` accessor to always return null. Since the `<template>` itself will only exist during parsing, and will be removed once the shadow root is attached and the `<template>` contents moved into the `#shadowroot`, this shouldn't cause any interop problems. It will just eliminate the possibility that script can come in and see the contents. This actually feels like a good improvement to the proposal overall - it should further reduce the possibility of corner case security issues.

2. There is a race between declarative and imperative shadow dom. In the case where an async script will eventually call `attachShadow()`, and a declarative shadow root is defined in the HTML, either one could "win".

Here, I think it's important to recognize that this is a fundamental problem with almost any declarative solution. Since Shadow DOM only allows one shadow root, if there are two things trying to create one, there will be a race.

But importantly, I think this is ok. It can be intelligently handled by component authors, but even in the case of "DSD unaware" components, both cases seem ok:

a. In the "normal" case, the declarative shadow root "wins" the race. Then the component script executes and calls `attachShadow()`. Per my comment above, that call to `attachShadow()` removes the contents of the declaratively-created shadow root and returns it (empty) to the component. The component then populates it and moves on with life. This is not performance-ideal, because the work is done twice. But in the case of "DSD-unaware" components, we're just trying to not break things.

b. In the "backwards" case, the `attachShadow()` call from the component "wins" the race. Then the declarative content finishes parsing, and the parser tries to attach the declarative shadow root. In this case, that attachment will fail, and the declarative contents will be discarded. Here again, not performance-ideal, but everything keeps working correctly.

In the case of a "DSD **aware**" component, both situations can be properly detected. The [871 proposal](https://github.com/w3c/webcomponents/issues/871) addresses making sure components have access to existing `#shadowroot`s, so that they can deal with both case a. and b. above in a performance-ideal way.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/831#issuecomment-608129380