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

[Justin Fagnani]

On Fri, Apr 22, 2016 at 8:24 PM, Anne van Kesteren  wrote:

> On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea  wrote:
> > 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).
>
> I don't think anyone disagrees with that in principle, but in practice
> that would require refactoring huge amounts of code which will
> basically not happen anytime soon. Better to iterate in smaller steps.
>

The implied key point here is that we can relax restrictions in the future,
but it's difficult-to-impossible to tighten restrictions.



>
> --
> https://annevankesteren.nl/
>
>

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

[Anne van Kesteren]

On Sat, Apr 23, 2016 at 3:08 AM, /#!/JoePea  wrote:
> 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).

I don't think anyone disagrees with that in principle, but in practice
that would require refactoring huge amounts of code which will
basically not happen anytime soon. Better to iterate in smaller steps.


-- 
https://annevankesteren.nl/

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

[/#!/JoePea]

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  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  wrote:
>
>> On Wed, Apr 13, 2016 at 1:09 PM, Tab Atkins Jr. 
>> 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
>