W3C home > Mailing lists > Public > www-style@w3.org > June 2013

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

From: Glenn Adams <glenn@skynav.com>
Date: Sat, 8 Jun 2013 17:01:07 +0900
Message-ID: <CACQ=j+d-XsPd_Dt-ZGdP2JeJy7Xo0tMvK9ifKqF+CoV+c-zZZw@mail.gmail.com>
To: Alex Russell <slightlyoff@google.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, W3C Style <www-style@w3.org>, Mark Miller <erights@google.com>, Anne van Kesteren <annevk@annevk.nl>, "www-tag@w3.org List" <www-tag@w3.org>, Yehuda Katz <wycats@gmail.com>, Erik Arvidsson <arv@google.com>, Dave Herman <dherman@mozilla.com>
On Sat, Jun 8, 2013 at 4:54 PM, Alex Russell <slightlyoff@google.com> wrote:

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

I hope your optimism is borne out by future facts, particularly if this
group goes down the path as an Early Adopter of this "future future". As a
point of note, what TC39 does put into a spec does matter for those of us
who often have to abide by final, SDO published specifications, and not
merely so-called "living standard" snapshots of a spec-du-jour.

> 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.
Received on Saturday, 8 June 2013 08:01:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:30 UTC