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

> Can you elaborate on this concern?

If I'm making `<distributable-widget>`, I have no control over how it's going to be consumed — whether it's going to be in an app that uses a WC SSR framework, or if it's going to be used in a document without declarative shadow DOM, or if it's going to be created programmatically. So at the very least, the constructor is going to need to accommodate both the case where declarative shadow DOM exists, and the case where it doesn't:

```js
if (this.shadowRoot) {
  this.foo = this.shadowRoot.querySelector('.foo');
  // ...
} else {
  this.attachShadow({ mode: 'open' });
  this.foo = document.createElement('div');
  this.foo.className = 'foo';
  // ...
  this.shadowRoot.append(this.foo, ...);
}
```

But that lack of control extends to the *content* of the declarative shadow DOM. It's very easy to imagine scenarios in which there's a version mismatch (including version changes that aren't considered breaking, because changing a shadow DOM classname could be considered an internal implementation detail)...

```html
<distributable-widget>
  <!-- code manually copied and pasted from some documentation on day 1 -->
  <template shadowroot="open">
    <div class="not-foo">...</div>
    ...
  </template>
</distributable-widget>

<!-- oops, only a major version specified! we get version 1.0.1, released on day 2 -->
<script type="module" src="https://unpkg.com/distributable-widget@1"></script>
```

...or something as simple as a misconfigured HTML minifier treats whitespace in a way that causes the DOM structure to be just different enough that `this.p = element.childNodes[3]` no longer works.

We might argue that these fall under 'user error', but regardless, we're introducing a source of brittleness that would be extremely difficult to debug.

-- 
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-586407187