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

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

From: Mark S. Miller <erights@google.com>
Date: Sat, 8 Jun 2013 02:38:24 -0700
Message-ID: <CABHxS9i4x8CFvnSoxvq1irf940dnBiUQDvM6pcnbVKLekrY-Kg@mail.gmail.com>
To: Glenn Adams <glenn@skynav.com>
Cc: Alex Russell <slightlyoff@google.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, W3C Style <www-style@w3.org>, 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>
I agree with all but one sentence of Alex's message. Unfortunately, the
sentence in question is bold. Object.observe reached an official consensus
in TC39, not just in broad strokes but in details. It is in fact the right
precedent for thinking about Promises. Object.observe happened on a fast
track because a) people were eager for it soon, and b) Rafael did a superb
job of getting the details right in multiple ways -- all of which mattered.
Even then, what TC39 does from here is not moot, though it is unlikely to
be disruptive unless a bad problem is found. I find the use of the term
"moot" to be entirely counter-productive -- asking for a fight where none
is needed.

I believe promises are set to arrive at the happy state enjoyed by
Object.observe quickly. But they are not there yet. At the last meeting, we
agreed that promises would be in ES7. And we narrowed down the design space
to two proposal skeletons -- named in <
http://wiki.ecmascript.org/lib/exe/fetch.php?id=strawman%3Aconcurrency&media=strawman:promisesvsmonads2.pdf>
as AP2 and AP3. The meeting broke up without declaring either one an
official consensus -- and a good thing too. The meeting ended with TC39
leaning towards AP3. Tab (the inventor of the clever AP2 variant) then made
compelling arguments on es-discuss for the superiority of AP2. I see much
agreement and no resistance to choosing AP2 over AP3. I expect, with high
probability, that TC39 will prefer AP2 over AP3 when it next meets. But we
have no process for arriving at a declared consensus between meetings,
especially when it contradicts the almost-agreement we had last time we met.

On a private thread, Tab is working with us to get AP2 ironed out into a
real spec quickly. I am very hopeful about this. But today AP2 is currently
a sketch, not a full fleshed out spec in which the details are pinned down.
Each of these details is a conversation and will be on the table at TC39. I
am very hopeful that Promises will arrive at the happy state of
Object.observe soon, but it hasn't happened yet. The care with which the
Object.observe API was presented and examined has only barely begun with
Promises.





On Sat, Jun 8, 2013 at 1:01 AM, Glenn Adams <glenn@skynav.com> wrote:

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


-- 
    Cheers,
    --MarkM
Received on Saturday, 8 June 2013 09:38:52 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:20 UTC