Re: Offline transcript

This is a new perspective to me:

> A prolyfill has be standardizable, it doesn't have to be standardized.

To be clear: I do not disagree. I am saying I don't think we've ever clearly stated it that way have we?

Further: My dislike of prefixing is to this point. I would prefer to write against a "standard" goal. Which would imply that I write my implementation against a "standard" API. While this means in prollyfill it wouldn't be a recognized standard by any standards body immediately it does mean that my implementation code is choosing it as "standard". If I as an author don't care about standards in any way - I'm happy with prefixing. On the other hand if it's important to me than prefixing feels wrong.




On Dec 19, 2012, at 10:34 AM, François REMY <francois.remy.dev@outlook.com> wrote:

> It's all assumptions right? A prollyfill is assuming a signature/API to be standard someday. A polyfill is assuming that a standard signature/API is to work a certain way.
>  
> Not necessarily.
>  
> When you write a JavaScript framework, you don’t expect browsers to implement the functions you implemented, you just expect them to copy you on some key points if it turns out your framework is popular.
>  
> To me, prolyfills are not necessarily leading to implemented ‘native’ versions. It’s quite possible that ‘nich’ use cases remains in the state of prolyfills for years until, maybe, they become mainstream (and when they will, maybe the API of the prolyfill will prove inappropriate).
>  
> A prolyfill has be standardizable, it doesn't have to be standardized.