Re: Basic processes

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



On Nov 19, 2012, at 9:47 AM, Brian Kardell <bkardell@gmail.com> wrote:

> 
> 
> On Sun, Nov 18, 2012 at 5:41 PM, Brian Kardell <bkardell@gmail.com> wrote:
> 
> Brian Kardell :: @bkardell :: hitchjs.com
> 
> 
> On Nov 18, 2012 4:45 PM, "Marcos Caceres" <w3c@marcosc.com> wrote:
> >
> >
> >
> > On Sunday, 18 November 2012 at 20:44, Brian Kardell wrote:
> >
> > >
> > > Ok, Mozilla's Daniel Buchner suggested that we consider this one, maybe the right thing to do is struggle thought how to get started on one, I am hoping he joins the list as well, he expressed some interest:
> > >
> > >
> > > http://www.backalleycoder.com/2012/08/06/css-selector-listeners/
> > >
> > >
> > > maybe the best thing to do is to just dig into discussions as I know that similar ideas are important in my/Clint's Hitchjs and have been illustrated by (I think) Raphael in http://code.google.com/p/mutation-summary/ and further discussions have been had by myself and Francois (and a few other W3C folks offlist) with regard to how this might be related to our own CSS Custom Properties proposal/fork of variableshttp://fremycompany.com/TR/2012/ED-css-custom/
> > >
> > >
> > > I don't suggest that our group's goal is to conclude there is one true way, rather to share and discuss and promote both competition and cooperation/bettering of ideas through cross-pollenation.
> > >
> > >
> > > So - given this, how would we start?
> > First, lets list what you think the goals of the group are. Then we can talk about deliverables that meet those goals.
> >
> 
> Ok, I think these are mostly very high level goals that we already agree on, but ok let's go through this excersize first for clarity.
> 
> > Here is my list:
> >
> > 1. investigate/research current poly/prollyfill strategies to help educate dev community.
> >
> > User scenario: Adam wants to use feature X of spec Y, but it's not supported or is buggy. Adam wants to know what is a good way to write code to fill/fix that gap, but in a way that best serves users of today and tomorrow.
> >
> > Deliverables: findings document of what works/what doesn't in both cases.
> >
> 
> I would seperate this distinctly as "polyfill" and mention that there are degrees of compatibility with these as well - the further back you try to fill compatibility the harder/less efficient it is.  I think part of the goals for polyfills specifically should be:
> 
> *  a sort of caniuse for polyfills which has a way to reference/measure fidelity and version compatibility.
> 
> * a place to take a fuzzy idea (or even an implementation) to something more formal (i.e. its not really a prollyfill until you have a draft proposal) and through several pairs of eyes of people who are likely looking at similar thing to see how it competes with/helps/might otherwise relate to other works - basically, this is like the genetic mixing pool for idea as they create variance and the more well adapted become mature.
> 
> > 2. Come up with a (potentially) new way to do poly/prollyfills based on 1 (and perhaps enable 4, below).
> >
> > User scenario: Mary wants to fix or fill a feature in a browser but wants to make sure that what she codes will be as close as possible to the spec that defines the broken/missing feature. Instead of reinventing the wheel, Mary uses [thing] to help her create a fast, efficient, backwards/future compatible poly/prollyfill.
> 
> > Deliverable: a [thing] that allows developers to create polyfills that are robust and embody best practices (i.e., not harmful to the Web, don't tax users who don't need them).
> 
> Sure, or maybe even a few "things", potentially even competing or parallel things.
> 
> > 3. Investigate and document what is needed so developers can build their own stuff on the Web platform (i.e., prollyfills).
> >
> > User scenario: George, a crazy-smart Dev, is on the cutting edge of development. While working on a project, he realises that if he could add X to the Web platform natively then Y would be orders of magnitude easier (and users would be all round better served). George sets out to build his idea using the Web technology available to him. Using guidance from prollyfill.org, he builds a successful prollyfill.
> 
> > Deliverables: document and/or direct-lobbying to W3C working groups so that devs get the functionality they need to innovate.
> 
> I think there are more "things" (see above note in #2) here than for pollyfills, but, other than that - yes.
> 
> > 4. Establish a vibrant poly/prollyfill ecosystem/community that enables people to find/share these things - as well as get access to useful information.
> > Deliverables: some kind of centralised/searchable repository that allows devs to both search and submit poly/prollyfills.
> 
> > User scenario: Tom has fixed annoying bug X in browsers Y, and Z! Now he needs a place to share it. Tom submits his code to prollyfill for review - where it is put through a robust set of tests. Sandy wants to use Tom's code, but is unsure of it's quality. She sees what sites currently using Tom's code in production - as well as user comments.
> >
> 
> if you got rid of the first sentence which I think is misleading, then yes exactly.
> 
> This is precisely why I mentioned taking a specific case through some discussion though, as that one clearly has various
> 
> > Kind regards,
> > Marcos
> >
> > --
> > Marcos Caceres
> > http://datadriven.com.au
> >
> >
> >
> 
> 
> 
> I'd like to make a suggestion to the group... I agree with the points above as all being fine goals - but the scope is really huge and I think that the prollyfill space is big enough from a work standpoint all on its own for now without even wading into polyfills or shims - I also think (personally) that it is the most important aspect and currently totally unfilled.... 
> 
> How do you all feel about focusing there - at least for starters?  
>