{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/webcomponents/issues/499","repository_url":"https://api.github.com/repos/w3c/webcomponents","labels_url":"https://api.github.com/repos/w3c/webcomponents/issues/499/labels{/name}","comments_url":"https://api.github.com/repos/w3c/webcomponents/issues/499/comments","events_url":"https://api.github.com/repos/w3c/webcomponents/issues/499/events","html_url":"https://github.com/w3c/webcomponents/issues/499","id":154242010,"number":499,"title":"Alternative proposal for closed shadow DOM","user":{"login":"mrmr1993","id":1847343,"avatar_url":"https://avatars.githubusercontent.com/u/1847343?v=3","gravatar_id":"","url":"https://api.github.com/users/mrmr1993","html_url":"https://github.com/mrmr1993","followers_url":"https://api.github.com/users/mrmr1993/followers","following_url":"https://api.github.com/users/mrmr1993/following{/other_user}","gists_url":"https://api.github.com/users/mrmr1993/gists{/gist_id}","starred_url":"https://api.github.com/users/mrmr1993/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mrmr1993/subscriptions","organizations_url":"https://api.github.com/users/mrmr1993/orgs","repos_url":"https://api.github.com/users/mrmr1993/repos","events_url":"https://api.github.com/users/mrmr1993/events{/privacy}","received_events_url":"https://api.github.com/users/mrmr1993/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/w3c/webcomponents/labels/shadow-dom","name":"shadow-dom","color":"207de5"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":44,"created_at":"2016-05-11T13:21:14Z","updated_at":"2016-06-13T23:43:59Z","closed_at":null,"body":"The `closed` flag for web components doesn't seem to have a clear purpose, and has several issues.\r\n\r\nSecurity:\r\n------------\r\n* Current security of closed components from the page is illusory\r\n  - A page can hijack the registration of closed components (via https://github.com/w3c/webcomponents/issues/354#issuecomment-162383744) with\r\n```js\r\nvar originalAttachShadow = Element.prototype.attachShadow;\r\nElement.prototype.attachShadow = function(options) {\r\n    options['mode'] = 'open';\r\n    return originalAttachShadow(options);\r\n}\r\n```\r\n  - They share a javascript context with the main page, so there's a reasonable chance of accidentally leaking the shadow DOM.\r\n    + hooking `Element.prototype.addEventListener` is an easy example, and can't be closed without some webcompat breakage.\r\n    + The [`Proxy`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Proxy) object provides similar opportunities when hooking getters.\r\n\r\n* Security is asymmetric.\r\n  - The host page has to implicitly trust the component with its important data (session cookies, password fields, etc.).\r\n  - The host page cannot easily place any restrictions on the behaviour of the scripts governing the component.\r\n\r\nIntegrity:\r\n------------\r\n* As above, the shared javascript context creates ample opportunity for leaking the shadow DOM.\r\n* The host page has no guarantees that the web component code will not interfere with the it outside of  the component element.\r\n\r\nAutomation, accessibility & testing:\r\n----------------------------------------------\r\n* Currently spec breaks all of these. See #354.\r\n\r\nTaking 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.\r\n\r\nProposed alternative:\r\n----------------------------\r\n* Keep majority of shadow DOM spec.\r\n* Remove `ShadowRootMode` and all of its consequences from the shadow DOM spec.\r\n* Introduce a new element (say `<component-iframe>`) with the same attributes, DOM interfaces and behaviour as  `<iframe>`, except\r\n  - 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).\r\n  - a DOM interface is added to the `<component-iframe>`'s `window` for registering API functions for the component, e.g.\r\n    + `window.registerComponentMethod(name, apiFunction)` to add a method\r\n    + `window.unregisterComponentMethod(name, apiFunction)` to remove a previously added method (functionally similar to `removeEventListener` elsewhere).\r\n  - a DOM interface is added to the `<component-iframe>` `HTMLElement` for accessing the registered API, e.g.\r\n    + `HTMLComponentIframeElement.getRegisteredComponentMethods()` to list the added methods\r\n    + `HTMLComponentIframeElement.NAME(...)` where `NAME` is the `name` argument for a method added via `registerComponentMethod`.\r\n  - the `<component-iframe>` should begin loading before being inserted into the document\r\n    + this allows it to process API calls, perform initialisation, etc. before it is displayed to the user.\r\n    + 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)).\r\n    + this allows the component respond to API calls and perform initialisation before it is inserted into the document, if necessary.\r\n\r\nIs this reasonable or even doable as an alternative?\r\n\r\n/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?"},"comment":{"url":"https://api.github.com/repos/w3c/webcomponents/issues/comments/225740736","html_url":"https://github.com/w3c/webcomponents/issues/499#issuecomment-225740736","issue_url":"https://api.github.com/repos/w3c/webcomponents/issues/499","id":225740736,"user":{"login":"treshugart","id":136556,"avatar_url":"https://avatars.githubusercontent.com/u/136556?v=3","gravatar_id":"","url":"https://api.github.com/users/treshugart","html_url":"https://github.com/treshugart","followers_url":"https://api.github.com/users/treshugart/followers","following_url":"https://api.github.com/users/treshugart/following{/other_user}","gists_url":"https://api.github.com/users/treshugart/gists{/gist_id}","starred_url":"https://api.github.com/users/treshugart/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/treshugart/subscriptions","organizations_url":"https://api.github.com/users/treshugart/orgs","repos_url":"https://api.github.com/users/treshugart/repos","events_url":"https://api.github.com/users/treshugart/events{/privacy}","received_events_url":"https://api.github.com/users/treshugart/received_events","type":"User","site_admin":false},"created_at":"2016-06-13T23:43:58Z","updated_at":"2016-06-13T23:43:58Z","body":"FWIW I predict that if there isn't a method for reading a closed tree, the community will be very quick to override `attachShadow()` and it will become common practice. If that's acceptable then so be it. If not, then there is a need for a way to access them non-destructively."}}
{"actor":{"display_login":"treshugart"}}