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

On Mon, Nov 12, 2012 at 12:16 PM, Marcos Caceres <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.
>
>

Received on Monday, 12 November 2012 17:47:44 UTC