Re: Scope of the Extensible Web Community Group [via Extensible Web Community Group]

On Monday, November 12, 2012 at 4:08 PM, François REMY wrote:

> Great start point, indeed :-) This is something like that I was looking for,
> we can probably use this as a base for our work.
>  
I think that is a good idea. I generally grab polyfill links from there when I need them. I imagine I'm not alone there.    
>  
>  
> | Whom do you intend to target with "get the polyfill concept “known”"?
> Firstly, W3C editors. At this time, too few of them think about writing
> (forward) polyfills for the features they spec.  

With all due respect, my experience has been the opposite (with 5-6 years on Webapps WG, and various other WGs). However, if you have some examples as to where this has happened, I would really like to hear it.  

I can point you to a few examples where polyfills exist. Look at, for example this early XBL imp:
http://dev.w3.org/2006/waf/XBLImpl/

Another I came across recently was the V8 JS 18n API (implemented in JS, but ships in Chrome!). I also know that DAP spoke of making JS implementations/prototypes, but not sure if they did. Or they didn't have to, because APIs landed in Firefox mobile pretty quickly thanks to the Moz guys.  

So, there are two counter points to this:  

1. Editors don't need to do this, because they have *real browsers* to code against.  
2. Standardized technology is usually pre-coded into browsers and then standardized.   

It is actually better that Editors not worry about polyfills and then let other people build implementations (a polyfill is a valid implementation, hence counts towards standardization in the W3C Process). That way, there is no programming language bias in the spec; and thus the polyfill can serve as proof that the spec can be implemented. This makes sure implementations are language neutral.  

> Also, when people are
> making feature requests, they should provide a prolyfill to show what they
> would like to get added to the web standards (and why).

That would be good.   
> I noticed it's
> pretty hard for most people to write specifications, but most authors find
> it easy to write code.

Yes, there are people who have abandoned the prose approach. For example, the Oz project (i.e., the new OAuth 2.0) won't have a spec, only code. Writing specs suck :)  
> I want to make it a reflex: when you need a feature
> that no browser implement, you start by making a prolyfill to get an idea of
> how easy it's to add the feature and what are the challenges before throwing
> the idea somewhere on the web, because spec editors are probably not
> interested in doing this work because they don't need the feature you want.

This is exactly what we are doing over in Responsive Images CG… but we also have a Chromium build. Sometimes, you can't actually capture the nuances through Javascript (or you end up with a distorted view of how browsers _actually_ work). See, for example:  
https://github.com/ResponsiveImagesCG/ri-usecases/issues/16  
  
> So, by "advertising polyfills", I meant "get people confident they can write
> some". And getting them confident of that requires templates, samples and
> guidelines.  

Agreed.   
> And to make sure it's easy to write polyfills, we need to
> convince W3C members to add features to the languages that make creating
> them easy (and so we need to convince them that the time they need to get
> that right is well-spend time). Is that more evident now?

It is, but I still don't think we should bug editors about this. We should bug people writing polyfills to learn Web IDL, etc. I've started writing a Learn Web IDL for Web Devs (was actually going to try to write a book about it, but it's quite time consuming). I can contribute what little I have right now. Still not sure what the best way to teach people Web IDL is… hands on… videos… etc.  

> | From experience, any guidelines [...] needs to be a living document from
> the start
> Certainly. I think the wiki is the best solution for the guidelines, and
> github for the templates/framework.
>  

Ok, lets think about requirements here instead of solutions first.   
> | Added some "prior art" articles to the wiki, which I thought wererelevant here
> Perfect, this is totally relevant. I already saw most of them, but not all
> so I guess I've some reading work to push on the stack ;-)

Me too! I've not read them… I just did a Google search and those were the first ones that came up :)

Received on Monday, 12 November 2012 17:39:30 UTC