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 <div> would use the native DIV. But, why not let the user define
what a <div> 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? <div>,
<input>, 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 <amp-img> element could just be
<img>.
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 <nick.dugg...@gmail.com> 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 <trus...@gmail.com> wrote:
>>
>> I personally don't like this limitation. I think Custom Elements would
>> be better if we could create elements that have <any> <name> <that>
>> <we> <want>, 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) //
>> <myelement> or <MyElement>
>>
>> const frag = document.createDocumentFragment()
>> frag.innerHTML = `
>> <div>
>> <MyElement>
>> ...
>> </MyElement>
>> </div>
>> `
>> 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
>>
>
