65 | What is the benefit of using this module?
66 |
67 |
68 | Beside solving this [long outstanding bug](https://github.com/whatwg/html/issues/5782) out of the box, the feature detection for builtin extends is both ugly and not really Web friendly.
69 |
70 | One could simply include [@ungap/custom-elements](https://github.com/ungap/custom-elements#readme) polyfill on top of each page and call it a day, but I wanted to have only the missing part, builtin extends, embedded in a module, and this helper is perfect for that purpose.
71 |
72 | On top of that, I really don't like the ugly dance needed to register builtin extends, so that having a tiny utility that simplifies their definition seemed to be about right.
73 |
74 | ```js
75 | // without this module
76 | customElements.define(
77 | 'my-div',
78 | class extends HTMLDivElement {},
79 | {extends: 'div'}
80 | );
81 |
82 | // with this module
83 | import {define, HTML} from 'vanilla-elements';
84 | define('my-div', class extends HTML.Div {});
85 | ```
86 |
87 | As we can see, the definition through this module is more compact, elegant, and natural, than its native counter-part, and that's about it.
88 |
89 |
90 |
91 |
92 |
93 | Why isn't the polyfill included by default?
94 |
95 |
96 | The only browser that needs a polyfill for builtin extends is Safari / WebKit, and it needs it only for builtin extends, but not everyone develops for the Web, and not everyone uses builtin extends, so the sane default is to provide a minimal utility that simplifies custom elements registration that works out of the box in every modern browser.
97 |
98 | Whenever the target needs to include Safari / WebKit, and builtin extends are used, it takes nothing to switch import from `vanilla-elements` to `vanilla-elements/poly` or use [an import-map](https://gist.github.com/WebReflection/5fc85856bba3d6eef794877fb5fa2a52) workaround to load the poly only in Safari.
99 |
100 |
101 | ```html
102 |
103 |
116 | ```
117 |
118 |
119 |
120 |
121 |