- 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