W3C home > Mailing lists > Public > public-nextweb@w3.org > July 2013

Re: Prollyfills and the global namespace / multi-fills

From: Michael Mullins <webdesserts@gmail.com>
Date: Thu, 04 Jul 2013 01:08:04 +0200
Message-ID: <CAMNOm+w5t4+n7u5d5buRbYR-MDA2nLx0rZ+WXTCOeR1zJh2QqA@mail.gmail.com>
To: "Brian Kardell" <bkardell@gmail.com>
Cc: public-nextweb-request@w3.org
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
Received on Thursday, 4 July 2013 09:11:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:54 UTC