> 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
