Re: Prollyfills and the global namespace / multi-fills

I agree that we should be namespacing Prolyfills in some form. I don't  
think that this is unique to prolyfills and developers should be future  
proofing their namespaces for normal libraries as well (and really what's  
the difference between a normal library and a prolyfill when you're only  
adding functions? Technically any library could be adopted by the W3C, no?)

However I think this becomes a bit more of an issue when you consider the  
many types of prolys a developer might want to make. Future proofing might  
be a bit more difficult in these cases:

CSS properties and HTML attributes
-webkit- like prefixing? -proly-? And what about CSS selectors?

Syntax Changes
what if you were proposing sass-like functions or mixins for CSS or a new  
function(){} wrapper in JS? How would you future proof this?

Object Extension
Using the example of prototype.js again, do we make a new prolyArray.map()  
or do we reserve a namespace on that object (e.g. Array.proly.map())?

I feel that these are all problems that would be difficult to solve with a  
single framework. Maybe a toolset would be better e.g. a tool for  
prolyfills that require JSparsing vs. a tool that just adds some functions  
and manages namespace collisions.

I realize that ideally a prolyfill builds off of those lower level  
components (e.g. an interface for defining your own CSS selectors) and  
file parsing wouldn't be necessary. But until those interfaces are in  
place I feel that future proofing some of these things will be difficult.

-- 
- Michael Mullins