[w3c/webcomponents] Alternative proposal for closed shadow DOM (#499)

The `closed` flag for web components doesn't seem to have a clear purpose, and has several issues.

Security:
------------
* Current security of closed components from the page is illusory
  - A page can hijack the registration of closed components (via https://github.com/w3c/webcomponents/issues/354#issuecomment-162383744) with
```js
var originalAttachShadow = Element.prototype.attachShadow;
Element.prototype.attachShadow = function(options) {
    options['mode'] = 'open';
    return originalAttachShadow(options);
}
```
  - They share a javascript context with the main page, so there's a reasonable chance of accidentally leaking the shadow DOM.
    + hooking `Element.prototype.addEventListener` is an easy example, and can't be closed without some webcompat breakage.
    + The [`Proxy`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy) object provides similar opportunities when hook getters.
* Security is asymmetric.
  - The host page has to implicitly trust the component with its important data (session cookies, password fields, etc.).
  - The host page cannot easily place any restrictions on the behaviour of the scripts governing the component.

Integrity:
------------
* As above, the shared javascript context creates ample opportunity for leaking the shadow DOM.
* The host page has no guarantees that the web component code will not interfere with the it outside of  the component element.

Automation, accessibility & testing:
----------------------------------------------
* Currently spec breaks all of these. See #354.

Taking these into account, it seems that a closed shadow DOM is little better than an open shadow DOM in any of the aspects it might hope to be, and causes problems for outside interaction with pages.

Proposed alternative:
----------------------------
* Keep majority of shadow DOM spec.
* Remove `ShadowRootMode` and all of its consequences from the shadow DOM spec.
* Introduce a new element (say `<component-iframe>`) with the same attributes, DOM interfaces and behaviour as  `<iframe>`, except
  - children of `<component-iframe>` are assigned to `<slot>`s in the document tree of the `<iframe>` using analogues of the [slotting algorithm (§3.2)](https://w3c.github.io/webcomponents/spec/shadow/#h-slotting-algorithm), [assigned nodes algorithm (§3.3)](https://w3c.github.io/webcomponents/spec/shadow/#assigned-nodes-algorithm), and [distributed nodes algorithm (§3.4)](https://w3c.github.io/webcomponents/spec/shadow/#h-distributed-nodes-algorithm).
  - a DOM interface is added to the `<component-iframe>`'s `window` for registering API functions for the component, e.g.
    + `window.registerComponentMethod(name, apiFunction)` to add a method
    + `window.unregisterComponentMethod(name, apiFunction)` to remove a previously added method (functionally similar to `removeEventListener` elsewhere).
  - a DOM interface is added to the `<component-iframe>` `HTMLElement` for accessing the registered API, e.g.
    + `HTMLComponentIframeElement.getRegisteredComponentMethods()` to list the added methods
    + `HTMLComponentIframeElement.NAME(...)` where `NAME` is the `name` argument for a method added via `registerComponentMethod`.
  - the `<component-iframe>` should begin loading before being inserted into the document
    + this allows it to process API calls, perform initialisation, etc. before it is displayed to the user.
    + this could be achieved by adding a `load` method to `<component-iframe>` which creates the *nested browsing context* (which persists after insertion into/removal from a document) and *processes the iframe attributes* (see [iframe spec](https://dev.w3.org/html5/spec-preview/the-iframe-element.html)).
    + this allows the component respond to API calls and perform initialisation before it is inserted into the document, if necessary.

Is this reasonable or even doable as an alternative?

/cc @dylanb, you're the major voice against closed shadow DOMs in #354. Would this proposal address your concerns/is it something you could get behind?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/499