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

[/#!/JoePea]

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

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

[Takayoshi Kochi]

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