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
>

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

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.

[Tab Atkins Jr.]

On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea  wrote:
> What if custom Elements simply override existing ones then?
>
> ```js
> shadowRoot.registerElement('div', MyElement)
> ```

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.

Having a well-known common API is worthwhile.  (JS technically has
this problem, but replacing built-ins, when it's done, is typically
just to *expand* them.  And once modules finally ship, we'll have a
built-in module with pristine versions of all the built-ins, too.)

> If overriding native elements was documented, it'd be fine. By
> default, a blank document or shadow root has no elements registered,
> so  would use the native DIV. But, why not let the user define
> what a  is? There could optionally be a warning outputted to
> console:
>
> ```
> Warning: DIV was overridden: /path/to/some/file.js:123:4
> ```

This means every website that overrides any built-in element will have
never-ending console spam, which isn't great.

~TJ

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

[/#!/JoePea]

What if custom Elements simply override existing ones then?

```js
shadowRoot.registerElement('div', MyElement)
```

If overriding native elements was documented, it'd be fine. By
default, a blank document or shadow root has no elements registered,
so  would use the native DIV. But, why not let the user define
what a  is? There could optionally be a warning outputted to
console:

```
Warning: DIV was overridden: /path/to/some/file.js:123:4
```

^ shows where is happens so an end user can easily find and remove the
culprit if that is ever a problem. In JavaScript, we can override many
of the things on the global `window` object. It's the developer's job
to add (or remove) scripts that modify their `window` properties. Why
not give the same level of flexibility with DOM elements? ,
, etc, can just be treated as global variables, overridable.  I
don't think that would do too much harm.

Being able to override on a shadow-root basic could encapsulate the
cases where such overriding is needed.

Being able to override native elements would make some interesting use
cases possible too, like providing alternate functionality to
commonly-used elements without having to touch existing markup of an
existing app. For example, AMP's  element could just be
.

TLDR: browsers would still be able to add new native elements, while
users would be able to override them. Why not? Allowing this won't
break the web (since nothing is currently overridden to begin with).
Let's make both browser makers and web app authors live's better as
much as possible at the same time. Being able to override elements
would be such a compromise: browser developers can add new default
elements, while web app authors can choose to use them or not, or to
override them.

Riot.js likes not requiring hyphens too!
/#!/JoePea


On Wed, Apr 13, 2016 at 11:53 AM, Nick Dugger  wrote:
> I personal don't mind the hyphenation requirement for custom elements. Tab
> Atkins brings up a great point about ensuring that new elements will be able
> to be added to spec without worry of name conflicts with existing custom
> elements on the page. It's much more future proof, in my opinion.
>
> On Wed, Apr 13, 2016 at 1:12 PM, /#!/JoePea  wrote:
>>
>> I personally don't like this limitation. I think Custom Elements would
>> be better if we could create elements that have   
>>  , with the possible exception that we can't override the
>> native elements.
>>
>> Based on my previous email about registering elements on shadow roots,
>> I think being able to choose any name would make things just cleaner:
>>
>> ```js
>> //  --- SomeElement.js
>> import MyElement from './MyElement'
>>
>> export default
>> class SomeElement extends HTMLElement {
>> constructor() {
>> this.root = this.createShadowRoot()
>> this.root.registerElement('MyElement', MyElement) //
>>  or 
>>
>> const frag = document.createDocumentFragment()
>> frag.innerHTML = `
>> 
>>   
>>   ...
>>   
>> 
>> `
>> this.root.appendChild(frag)
>> }
>>
>> static get observedAttributes() { return [ ... ] }
>> connectedCallback() { ... }
>> disconnectedCallback() { ... }
>> attributeChangedCallback() { ... }
>> }
>>
>> //  --- app.js
>> import SomeElement from './SomeElement'
>>
>> // elements registered on the document won't cross into shadow roots
>> document.registerElement('SomeElement', SomeElement)
>> document.body.appendChild(document.createElement('someelement'))
>> ```
>>
>> /#!/JoePea
>>
>

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

[Nick Dugger]

I personal don't mind the hyphenation requirement for custom elements. Tab
Atkins brings up a great point about ensuring that new elements will be
able to be added to spec without worry of name conflicts with existing
custom elements on the page. It's much more future proof, in my opinion.

On Wed, Apr 13, 2016 at 1:12 PM, /#!/JoePea  wrote:

> I personally don't like this limitation. I think Custom Elements would
> be better if we could create elements that have   
>  , with the possible exception that we can't override the
> native elements.
>
> Based on my previous email about registering elements on shadow roots,
> I think being able to choose any name would make things just cleaner:
>
> ```js
> //  --- SomeElement.js
> import MyElement from './MyElement'
>
> export default
> class SomeElement extends HTMLElement {
> constructor() {
> this.root = this.createShadowRoot()
> this.root.registerElement('MyElement', MyElement) //
>  or 
>
> const frag = document.createDocumentFragment()
> frag.innerHTML = `
> 
>   
>   ...
>   
> 
> `
> this.root.appendChild(frag)
> }
>
> static get observedAttributes() { return [ ... ] }
> connectedCallback() { ... }
> disconnectedCallback() { ... }
> attributeChangedCallback() { ... }
> }
>
> //  --- app.js
> import SomeElement from './SomeElement'
>
> // elements registered on the document won't cross into shadow roots
> document.registerElement('SomeElement', SomeElement)
> document.body.appendChild(document.createElement('someelement'))
> ```
>
> /#!/JoePea
>
>

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

[Tab Atkins Jr.]

On Wed, Apr 13, 2016 at 11:12 AM, /#!/JoePea  wrote:
> I personally don't like this limitation. I think Custom Elements would
> be better if we could create elements that have   
>  , with the possible exception that we can't override the
> native elements.

This would prevent us from ever adding any new elements to the
language, or at least require us to do real-world usage checks and
avoid names that would break too many pages if we took it over.
Requiring a dash is a minimal cost to element authors, and permanently
avoids any clashes.

This is similar to CSS requiring custom properties to start with a
double-dash, like --foo.

~TJ