Re: Web MIDI polyfill

On Thu, Dec 13, 2012 at 7:04 PM, François REMY <
francois.remy.dev@outlook.com> wrote:

> The following point is included in our scope statement:
>
>    • Get the concept of “forward polyfill” known by the other W3C
>       groups and encourage spec editors to create prototypes for their
>       drafts *using prolyfils*.
>
> I therefore propose we drop the *using prolyfills* part and split that into
> two separate goals:
>
>    • Get the concept of “forward polyfill” known by the other WGs
>    • Encourage spec editors to create prototypes for their drafts
>

I support that - I would like to add a bullet about something like "create
a community of peer review, discovery and common efforts" and include in
the second bullet above something like "and help define and advocate a
lifecycle from idea to standard"



> I also agree that we should maybe explain what we mean by
> the following keywords in our scope statement, as thet may seem
> identical to newcomers :
>
> polyfill - prolyfill - shim
>


I think that I have blogged and written about this before... Pollyfill and
shim were terms coined with definitions by Remy Sharp.  Here is my best
definition, feel free to pick them apart, improve them or debate... Moving
in order from "closest to actual standard" to merely "some API":

- polyfill:  something which provides implementations for a stable and
mature draft or recommendation which is lacking native implementation in
one or more currently popular browser, but has native implementations
(sometimes while they are still prefixed, but not behind a flag).  Usually,
they use a simple "use the native unless it is not there" approach, so your
site can automatically upgrade to native as it becomes available.

- prollyfill:  something which provides implementation of a draft as the
draft matures and allows us to suss it out, pick it apart, provides
alternatives and decide what to natively implement.  Its intent is to
become a standard, it is tied to no particular browser implementation
(though it might only work in "modern browsers" in the current ecosystem -
it should work in all modern browsers), it is opted in by the author and
bound to an implementation version which tracks to the spec - so it won't
ever "break" (at least not for any rational reason) despite the fact that
the draft might evolve quite a bit.

- shim:  something which provides an alternative API to a mature API (even
a REC with wide implementation in modern browsers) in older browsers for
the sake of (usually rough) capability parity.  <-- NOTE: I don't think we
should concern ourselves with these... They have no draft an are actually
only a rough hop from the next bullet...

- libraries:  Just new API implementations with no draft and no intent to
become a standard, etc... These can be pretty micro and focused, but more
often than not they generally mix a lot of useful APIs into an attempt to
make it generally easier to complete (usually) common use-cases in Web
development. <--- NOTE:  I also don't think we should concern ourselves
with these.





-- 
Brian Kardell :: @briankardell :: hitchjs.com