Re: Alex Russell on Polyfills and some other thoughts...

|  I like prollyfills in that it allows us to potentially experiment
|  with tomorrow's stuff today. This brings up some important
|  architectural questions (i.e., avoiding a prollyfill becoming a
|  polyfill).

My thought is that this is more the responsability of the other WGs to make 
sure they transform "wanna-be-popular" prolyfills into native 
implementations as soon as possible, not really the one of the prolyfill 
author. According to you, what should a prolyfill author do to make sure 
this doens't become the case?

|  I'm interested in having a 1 to 1 match between HTML5
|  algorithms and prollyfills. So, when implementing a polyfill for an
|  element, a developer can just hook into those functions, as they
|  are the ones that are relied upon in the HTML5 spec.

Agree. A good prolyfill should try to follow the spec. However, implementing 
an ever-chaning spec is never without risk, you can't erase that fact.

|  Ideally, from APIs what I would like to see is a magical
|  framework that does the following: given a Web IDL
|  fragment and a set of corresponding values, the
|  framework spits out Javascript code that implements
|  a given interface for you.

A sort of code generator, you mean? I'm fond of code generators :D

I would love to work on that! I don't think it's gonna be difficult, what's 
will be more difficult will the "framework" as you call it (ie: the 
functions required to make the real implementation effective and close to 
the standards). The kind of things like we discussed last week (like "throw 
a new DOMException").

Received on Saturday, 17 November 2012 15:25:25 UTC