Re: Basic processes

On Mon, Nov 19, 2012 at 12:04 PM, Clint Hill <clint.hill@gmail.com> wrote:

> +1.
>
> I too think that involving "polyfill" at this time could be over-reach for
> the goal of Extensible Web Group. I feel we should focus on the
> "prollyfill" practice which is forward thinking and standards driving.
> Polyfill is more reverse direction and frankly doesn't need any help at the
> moment IMO.
>
> What is important about this group is to help coagulate the efforts of
> authors and browser implementors so that neither is impeded by the other.
>
> I don't feel we've sharpened the concept into a bite sized meal. I've used
> this to help articulate the difference to co-workers in the last few days
> and this is what made sense to them:
>
> Polyfill === "normalizing known/accepted standard across browsers"
> Prollyfill === "driving new/uncharted standard for browsers"
>
> If that understanding of the 2 is clear, then our group should be
> certainly focused on the latter. Which IMO would mean we don't necessarily
> need to focus on listing polyfills and translating them to prollyfills.
> Rather we ought to focus on an "engine" that helps authors create
> prollyfills. The "engine" is a Web IDL plus a parser, plus an API, plus a
> syntax and tooling for distribution/communication.
>
> I think the group should be building these things or at least focused in
> that way.
>
>
I'd like to see it just a bit more - like you said, we'd like to become a
repo for them and provide a kind of process where they can be discussed,
refined, etc.

WRT components involved in creating prollyfills - I don't know that there
is necessarily "one true way" - on some of them, let me give you an
example:  Parsing CSS could be an "on demand" thing - LESS has a way to do
this and so does Hitch and so does Adobe's prollyfill.  It seems like that
is not an unreasonable answer - but ultimately those wind up parsing into
some form that can actually be used, which could be done in a pre-processor
which could be written in any language.  I would like to see us discuss,
for example, what a good neutral model JS model might be for output of any
of them, that way it's modular and you could include the makers of
preprocessors in the discussions.  Working with the group, providing a JS
reference implementation would be a great idea (and potentially a
prollyfill itself if we wanted to propose that it might be done natively,
though I'm not sure that is a sellable idea), but providing the API hooks
necessary for lots of pre-processors to write to a common output for that
sort of thing is a bigger win and widens the usefulness/audience in a
really positive way IMO.