Re: Use of Futures/Promises in CSS Font Face APIs

On Sat, Jun 8, 2013 at 5:05 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Fri, Jun 7, 2013 at 9:03 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> > No.  Promises are entirely polyfillable in ES5.
>
> Or, to be more accurate, they're polyfillable in ES5 + setTimeout().
> The latter can't currently be expressed in pure ES, as we haven't yet
> added the concept of the event loop to the ES spec (it's planned for
> ES7, I believe),


We'll need some sort of a hook for the Module system in ES6, but yes, most
of it is slated for ES7. That said, there's a misconception floating around
this group (although not held by you, Tab) that should be put down as soon
as possible:

TC39's publication schedule no more defines when things get added to
runtimes than the final TR status for one of your work products does. Case
in point, Object.observe(): it's slated for ES7, but thanks to broad
consensus and early implementation work by Rafael Weinstein and Adam Klein,
it has gained the status of "accepted proposal". In CSS WG speak, this is
somewhere past FPWD and somewhere before LC, and that can happen *even
though the spec isn't slated to be finished for years.*
*
*
This is a good and healthy mode of work.

What's happening with Promises is different still: there is agreement with
the stakeholders in TC39 (cc'd) to work with the DOM maintainers to ensure
compatibility between the spec that eventually lands in ES7 and the DOM
spec that's necessary to allow implementations to move forward before TC39
moves into fully spec-ing ES7.

*That means that the entire question of what will TC39 do and what bits of
the event loop are spec'd are entirely moot*; they are a distraction (and
one hopes, not simply being used as an excuse).

This mode of collaboration between TC39 and DOM/CSSOM has, in the past,
been rare, but what you're seeing here is actually a *great* thing, and
something we should hope for more of. Web Platform APIs are TC39's largest
spec consumer, and yet our mutual understanding of the process and
terminology differences is pretty low. I hope this can be a first step in
building a bridge there.

Regards


> but that's irrelevant for our purposes, as the event
> loop *does* exist in de facto ES in every browser, and non-browser ES
> environments like Node.
>