Re: [Custom Elements] Not requiring hyphens in names.

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 <trusktr@gmail.com> wrote:

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


-- 
Takayoshi Kochi