- From: /#!/JoePea <trusktr@gmail.com>
- Date: Thu, 14 Apr 2016 15:01:05 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Nick Dugger <nick.dugger1@gmail.com>, public-webapps WG <public-webapps@w3.org>
On Wed, Apr 13, 2016 at 1:09 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > That means we lose the lingua franca that HTML provides; two > independent libraries can't ever depend on the core HTML elements, > because the other library might have overridden some of them. Based on my idea of registering elements on a per-shadow-root basis (https://discourse.wicg.io/t/proposal-register-custom-elements-onto-shadowdom-roots/1440), then libraries could use any native or custom elements that they want within their shadow roots. Shadow roots would provide encapsulation, and element registrations would be scoped to those shadow roots. There are two possible ways to deal with element registrations on the `document`: 1. Either elements registered on the `document` have effect across shadow roots, but shadow roots can override these registrations: ```js document.registerElement('foo-bar', SomeClass) // ... shadowRoot.registerElement('foo-bar', OtherClass) // takes precedence over the document registration. ``` 2. Or, document registrations simply wouldn't cross the shadow root boundary. I personally like the second option, leaving maximum control in the hands of the developer, regardless of some global script registering an element on the document that may encroach the scope of a shadow root. If a shadow root author really wants the same element, there's slightly more effort to also register that element with the shadow root, but the overall control outweighs this extra effort in my opinion. Then, if we add the ability to override native elements, we'll have something powerful, IMO. ```js // file1.js import BetterImageWithWebGLFilters from 'better-img' document.registerElement('img', BetterImageWithWebGLFilters) // file2.js let s = el.createShadowRoot() s.appendChild(document.createElement('img')) // uses native HTMLImageElement because document registration stops at shadow root boundary. // file3.js import BetterImageWithWebGLFilters from 'better-img' let s = el.createShadowRoot() s.registerElement('img', BetterImageWithWebGLFilters) s.appendChild(document.createElement('img')) // this person wants BetterImageWithWebGLFilters in their shadow root // file4.js let s = el.createShadowRoot() s.registerElement('div', AwesomeClass) // this does not affect other shadow roots or the document, it's contained within the shadow root. ``` This would be awesome I think. It'd allow for a level of encapsulation and modularization on a shadow-root basis (which can paired with Custom Elements very nicely). /#!/JoePea
Received on Thursday, 14 April 2016 22:02:12 UTC