Re: Custom-elements: document.registerPolyfillElement ?

2014-06-10 Thread Dominic Cooney
On Mon, Jun 9, 2014 at 4:00 PM, Brett Zamir bret...@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


Re: Custom-elements: document.registerPolyfillElement ?

2014-06-10 Thread Brett Zamir
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 bret...@gmail.com 
mailto:bret...@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





Custom-elements: document.registerPolyfillElement ?

2014-06-09 Thread Brett Zamir
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.


How about something like `document.registerPolyfillElement`?

As I envision it, it would, besides also allowing for elements without 
hyphens, behave in the same way as `document.registerElement` (I 
understand this will be replacing `document.register`), but if 
`document.createElement` would return anything besides 
`HTMLUnknownElement` for the supplied element name, it would immediately 
return that element's own constructor (or perhaps throw an exception if 
no constructor were allowed for that element). This would provide the 
added convenience of not having to feature detect existing support. Or 
perhaps `document.registerElement` could be supplied a flag to indicate 
a polyfill was intended.


(Maybe the mechanism could even allow one to polyfill specific methods 
of existing elements, taking advantage of `attributeChanged`, for example.)


Thanks,
Brett



Re: Custom-elements: document.registerPolyfillElement ?

2014-06-09 Thread Anne van Kesteren
On Tue, Jun 10, 2014 at 1:00 AM, Brett Zamir bret...@gmail.com wrote:
 How about something like `document.registerPolyfillElement`?

Native elements have access to more hooks and synchronous features not
available to custom elements. And we haven't fully explored what those
are yet so this seems a bit premature.


-- 
http://annevankesteren.nl/