Thanks, this is helpful to know, though I'd still prefer a solution at some point which didn't require one to use extra code and once the polyfill was no longer needed, requiring alteration of code to be semantically correct (e.g., if it no longer is a "x-polyfill-dialog" because the registration for it was removed) and non-redundant.

Best wishes,

On 6/10/2014 2:00 PM, Dominic Cooney wrote:
On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir < <>> wrote:

    I was looking to make a genuine polyfill for <dialog> (not just a
    shim), and I found Polymer's CustomElements helpful, but realized
    too late that the spec required "x-" prefixes.

    I still feel like it would be useful to have a means for polyfills
    to be built according to well-recognized semantics via a standard
    extension mechanism.

It is possible to do this using a "type extension". For example:

document.register('x-polyfill-dialog', {prototype: ..., extends: 'dialog'})

This produces a type extension of the HTMLUnknownElement with the tag name "dialog" in browsers that don't support dialog, and a type extension of the HTMLDialogElement of ones that do.

The only wrinkle is that markup must use <dialog is="x-polyfill-dialog">.

Your polyfill can degrade gracefully in whichever way you decide. For example, you could detect HTMLDialogElement and not register the Custom Element, in which case the markup will create unresolved type extensions of HTMLDialogElement that get the browser's native dialog. Or you could go ahead and register your polyfill anyway, in which case your prototype object would hide the browser's HTMLDialogElement prototype. Or you could do something dynamic inbetween.



Reply via email to