> This assumes you'll match

That's a good point. I agree for most APIs it's probably better to simply use 
polyfill code for all browsers. But some APIs have some extra benefits that 
might not be polyfillable. For example, the native version of web animations 
happen in a compositor thread, so google's web animations polyfill use native 
APIs when they exist and only provide polyfill when they don't.

> But it's not deprecated in browsers that don't support it

Probably I still don't quite understand how prollyfill works.

Let's say the prollyfill offered node._foo(), one browser shiped experimental 
node.foo(), users ignored that, and used our polyfilled version. Everyone was 
happy. Then other browsers are on board, this API becomes stable. Now, what 
should the prollyfill do?

Should it still ship node._foo() and expect users to use that when most 
browsers ship node.foo() and this API has a precise definition?

Or it should deprecate node._foo(), polyfill node.foo() for browsers still 
don't support it and encourage users to switch to node.foo()?

Or it should do something else?

I don't quite understand the oneliner you gave:

HTMLElement.prototype.foo = HTMLElement.prototype._foo;

Why would you want to overwrite a native API with polyfill? How does that work 
for users? Users can choose either native API or prollyfill's prefixed version 
and they will both use the polyfill?

> On Aug 7, 2015, at 7:07 AM, Brian Kardell <bkard...@gmail.com> wrote:
> On Thu, Aug 6, 2015 at 6:50 PM, Glen Huang <curvedm...@gmail.com> wrote:
>> @William @Matthew
>> Ah, thanks. Now I think prollyfill is prolly a good name. :)
>> @Brian
>> Actually, I had this pattern in mind:
>> When no browsers ship the API:
>> ```
>> if (HTMLElement.prototype.foo) {
>>  HTMLElement.prototype._foo = HTMLElement.prototype.foo;
>> } else {
>>  HTMLElement.prototype._foo = polyfill;
>> };
>> ```
> This assumes you'll match, which - again depending on how far you are
> might be a big bet... Personally, I wouldn't use that myself if
> writing something -- Seems a lot like  when people simply provided N
> versions of the same prefixed properties instead of just one, it has
> potential to go awry... No one can actually vary because they've done
> the equivalent of shipping the unprefixed thing inadvertently
> intending it to be an experiment, but it wasnt.
>> When at least two browsers ship this API:
>> ```
>> if (!HTMLElement.prototype.foo) {
>> HTMLElement.prototype.foo = polyfill;
>> }
>> HTMLElement.prototype._foo = function() {
>>  console.warn("deprecated");
>>  return this.foo();
>> };
>> ```
> But it's not deprecated in browsers that don't support it, it's a
> polyfill at that point and aside from the console.warn (which again,
> in this case seems incorrect in the message at least) it should be
> generally be identical to the oneliner I gave before - the prototype
> for _foo is the polyfill version.
> -- 
> Brian Kardell :: @briankardell :: hitchjs.com

Reply via email to