Re: Basic processes

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