dialog-polyfill
dialog-polyfill copied to clipboard
Consider exporting base class `HTMLDialogElement` for subclassing
First off, thanks for the polyfill. It seems to work.
Motive: my app is organized around custom elements, many of which are instantiated directly with new. I'm not concerned with tag name compatibility such as <dialog is=some-dialog> vs <some-dialog>. What's important is simply having the base class available.
I hacked together the following and it seems to work, but having it provided by the library would be better. Hopefully without increasing the size of the polyfill.
import dp from 'https://cdn.jsdelivr.net/npm/[email protected]/dist/dialog-polyfill.esm.min.js'
const HTMLDialogElement = window.HTMLDialogElement || class HTMLDialogElement extends HTMLElement {
constructor() {
super()
// Hack for the polyfill.
this.showModal = undefined
// Actual polyfill.
dp.forceRegisterDialog(this)
this.showPoly = this.show
this.showModalPoly = this.showModal
this.closePoly = this.close
delete this.show
delete this.showModal
delete this.close
}
// Allows `super.X` in subclasses.
show(...args) {return this.showPoly(...args)}
showModal(...args) {return this.showModalPoly(...args)}
close(...args) {return this.closePoly(...args)}
// Hack for the polyfill.
get localName() {return `dialog`}
}
I second this. However, I think the polyfill should define window.HTMLDialogElement accordingly by itself, not just export it. I ran into this exact problem and a polyfill should polyfill the missing functionality - HTMLDialogElement is part of this missing functionality.
Note that this is a somewhat rare use-case right now, since Safari does not support it (requires a tiny polyfill). But extending built-in elements is extremely useful in a certain web programming style and could spread ...
"a somewhat rare use-case right now" The GitHub web interface uses it now, and the user navigation will now break on any web browser that doesn't have HTMLDialogElement natively (most worringly, Firefox versions below 98).