Re: Basic processes

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?