- From: Brett Zamir <brettz9@gmail.com>
- Date: Tue, 10 Jun 2014 19:13:05 +0800
- To: Dominic Cooney <dominicc@google.com>
- CC: WebApps WG <public-webapps@w3.org>
- Message-ID: <5396E841.3070304@gmail.com>
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, Brett On 6/10/2014 2:00 PM, Dominic Cooney wrote: > On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir <brettz9@gmail.com > <mailto:brettz9@gmail.com>> 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. > > HTH, > > Dominic
Received on Tuesday, 10 June 2014 11:13:41 UTC