Re: Prollyfills and the global namespace / multi-fills

On Jul 3, 2013 7:16 PM, "Brian Kardell" <bkardell@gmail.com> wrote:
>
> 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?

There is a vendor prefixing model in CSS, and now with variables and other
coming proposals, we will have equivalent for authors.  Hitch makes use of
the vendor prefix syntax in a manner similar to web components - if it
begins with dash and you have imported you are set.  Forward compat stuff
is already there. Yay.

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

Anything that changes the core grammar would be out, but that's probably ok
- should be done with caution.  CSSOM leaves a kind of unfortunate hole
here atm however.

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