Re: Prollyfills and the global namespace / multi-fills

> > > Yes it is, it's supposed to exactly match (as much as it can in JS).
> >
> >
> > Well, it matches the *current* spec. If someone use that code in 
> > production,
> > in a few time it will stop to match.
>
> Why?

Because specs evolve... The whole point of the warning I oultined is to 
explicitely ask people not to implement the spec as-is because it's not 
stable. If we're doing it in JS, we're pretty much screwing the things 
totally because when browsers will want to implement the spec for real, they 
will break tons of websites using non-prefixed prolyfills. This is not an 
hypothetical future, it already happened a lot.



> > If the goal is to polyfill an existing REC/CR spec, it's okay not to use
> > prefixes, because you can test your spec against test cases, and you can
> > match existing implementations.
>
> The whole point of the stuff I'm building is so to avoid
> what is discussed in the manifesto: stop gawd awful
> APIs from being put into the platform _way_ before
> they get anywhere near CR (… even way before
> Last Call).

Honestly, I don't see how prefixing the implementation would change anything 
to that capability. However, I agree with Brian:

|   Marcos, if you are feeling brave, pass in window.
|   If you are someone evaluating for the spec, use
|   window. For everyday use in situations I would
|   really like to use prollyfills - personally, I think
|   that is a dangerous thing to do.

That's why we need modules, ie a way for people to choose themselves if they 
want prefixing or not (and prefixing should be the default).



> Ok, I can see where there could be potential clashes for
> unmaintained code. But I think this would be rare.

It's not rare at all. Most websites are unmaintained, and they hold the web 
platform back. Ask any implementor for stories where unmaintained websites 
slowed down the unprefixing or the introduction of new APIs because of 
conflicts, you'll see for yourself.



> I'm just thinking there is a differentiation to be made
> between a library and prollyfill (which is intended to
> inform a standardization process, for instance).

Prollyfills -can- inform standards bodies. But for that to be effecient, 
they have to be used on real websites. Sure it can be on demo websites, but 
as soon as it works, people will want to use it in production (why not?). 
We've to make sure this prollyfilling approach does not harm the web by 
spreading old versions of specs on the global namespaces other scripts 
mistakenly take for a native implementation.

Received on Wednesday, 3 July 2013 19:46:45 UTC