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

On Monday, November 12, 2012 at 5:47 PM, Brian Kardell wrote:

> On Mon, Nov 12, 2012 at 12:16 PM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> >  
> >  
> > On Monday, November 12, 2012 at 3:03 PM, Brian Kardell wrote:
> >  
> > >  
> > > On Nov 12, 2012 9:40 AM, "Marcos Caceres" <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> > > Marco,
> >  
> >  
> >  
> > Marcos ;)
>  
> Sorry, I knew that - silly autocomplete dictionary on my phone.
> Don't feel too bad - I get my share of emails beginning with "Brain"
> :)
>  
> > >  
> > > Yes it is somewhat related to developing and promoting best practices for polyfills...somewhat related to a group to review and critique their fidelity as you mentioned following the Web IDL. The fidelity of some of them is pretty awful and that will come back to bite authors.
> >  
> > Agreed.
> > > Much more than that though (a few things happened out of order and I think that is making it confusing) it was intented to be a place to discuss, encourage, promote, etc an idea that has been developing under a couple of names, until recently the best was "forward polyfills" then in October Alex Sexton coined the phrase "prollyfills" on Twitter.
> >  
> >  
> >  
> > Ok, yes. I've been making a lot of those too. For example:
> > http://specs.wacapps.net/webview/implementation/Webview.js
>  
>  
>  
> Yes - similar idea...
>  
>  
> >  
> > Also, over at the responsive images CG, we have our fair share of those (including some prollynotfills, as they have been labelled ;) ).
>  
> Yes, a large number of "prollyfills" will fail - this is actually an
> advantage as we will explain....
>  
>  
> > > We will link/post some links and articles in the next hours/days. The difference being that pollyfills are (or at least should be) conceptually something intended to "fill the gaps in native implementations a few browsers" of a fairly mature standard.
> >  
> > Agreed.
> > > The current prefixing model which couples experimental implementations with browsers has proven problematic on all sorts of fronts.
> >  
> >  
> >  
> > Exactly what those problems are I am really keen to hear about.
>  
> It depends on what you are trying to prollyfill. If it is an ECMA
> feature, there are few problem - that is probably why that group seems
> to embrace this idea more than most others. If you are trying to
> prollyfill a new pseudo-class selector or function in CSS, you have a
> lot to do and no "core" to build on. If you are trying to prollyfill
> something like Web Components - you have a lot of challenges. If you
> are trying to prollyfill something like Tab Atkins' Cascading
> Attribute Sheets which is very "like" CSS, but in many ways entirely
> different - you again have a lot of work to do. A lot of the
> challenges that all of these face have bits that are very, very
> similar -- a cooperative group that could help flesh them out,
> potentially help develop or make people aware of common reusable bits
> and maybe even advocate some new native APIs that would help could go
> a long way. Here's just one example: Adobe recently proposed
> something this way
> http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0508.html
> and later I got to talk to them as one of the owners of hitchjs which
> does a lot of the same things - Mozilla also runs x-tags which has a
> lot of overlap. Each one of those could have been much, much easier
> with cooperation - and ease would encourage more things to work this
> way.
>  
> >  
> > > The idea with a prollyfill is to provide experimental/reference implemenations for early drafts decoupled from the browsers themselves - hopefully in a "forward compatible" way.
> >  
> > Yep.
> > > This has all sorts of advantages and there are all sorts of ways to accomplish this which we will get into as we link up
> >  
> >  
> >  
> > There are also a ton of disadvantages/risks… specially if those things get into the wild (hence the "prolly" bit). Making sure we don't break the Web with the proliferation of prollyfills is a good thing :)
>  
> Potentially if we aren't careful - but there is a clear path where
> that needn't happen... The current prefix policy/wrapped up with the
> browser model has real problems in this area too - authors are
> generally encouraged to provide matching, unprefixed versions so that
> when the prefixed ones go away, they "just work" -- however, they are
> prefixed for a reason and it is quite possible that they won't. Most
> problems in this area seem to come from mucking around in the native
> space with something experimental. Prefixing early implementations
> from a source outside the browser ensures that these will just keep
> working - if they were good enough yesterday non-natively then there
> is no reason to assume that they are not good at least as good in the
> future as well. This is also advantageous in that experimental code
> can not only compete and fail but also iterate freely without anyone's
> hard-created code suddenly failing because the author is placed in
> charge of upgrades if/when they are available - not browser upgrades
> which the author has no control of. Ideally, successful prollyfills
> would inform native implementations and hopefully we graduate it to a
> pollyfill. Nice model.
>  
> > > - the present problems are that currently most of these are very difficult to build and the community is very fractured.
> >  
> > i think this is mostly by design. Adding new features to the web platform is generally done because there was just no other practical way to achieve something (e.g., device APIs).
> > > We would like to bring them together and help build and advocate common apis and lobby for necessary and helpful native apis where appropriate.
> > > Looking forward to the discussions.
> >  
> >  
> >  
> > Me too. Thanks for the clarifications. It's good to have some common terminology.  
Agree with everything above. I think the above eludes to how we should break up the problem (polyfilling APIs, CSS, HTML, etc.).   

--  
Marcos Caceres

Received on Monday, 12 November 2012 18:02:02 UTC