Re: Basic processes

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. 

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. 

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

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. 

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.  

Kind regards,
Marcos 

-- 
Marcos Caceres
http://datadriven.com.au

Received on Sunday, 18 November 2012 21:46:15 UTC