Re: Prollyfills and the global namespace / multi-fills

Please use this email to reply to michael's..

Michael, please use public-nextweb@w3.org instead of
public-nextweb-request@w3.org.
On Jul 3, 2013 7:07 PM, "Michael Mullins" <webdesserts@gmail.com> wrote:

> 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
>