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

Thanks for the link!

​I really believe that we should be allowed to name our elements with any
name we wish, and that they should override native elements (that is future
proof), and that overriding should be on some type of encapsulated basis
(for example, override within a shadow root and it won't affect other code
outside the shadow root).​


On Thursday, April 14, 2016, Takayoshi Kochi <kochi@google.com> wrote:

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