Just FYI, the idea of allowing non-hyphen elements if they contain non-ASCII characters which probably won't collide with future HTML elements was posted in the discussion: https://github.com/w3c/webcomponents/issues/239#issuecomment-190603674
On Fri, Apr 15, 2016 at 7:01 AM, /#!/JoePea <trus...@gmail.com> wrote: > On Wed, Apr 13, 2016 at 1:09 PM, Tab Atkins Jr. <jackalm...@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 > > -- Takayoshi Kochi