- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 13 Apr 2016 13:09:50 -0700
- To: "/#!/JoePea" <trusktr@gmail.com>
- Cc: Nick Dugger <nick.dugger1@gmail.com>, public-webapps WG <public-webapps@w3.org>
On Wed, Apr 13, 2016 at 12:33 PM, /#!/JoePea <trusktr@gmail.com> 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 <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
> ```
This means every website that overrides any built-in element will have
never-ending console spam, which isn't great.
~TJ
Received on Wednesday, 13 April 2016 20:10:39 UTC