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

On Sat, Jun 8, 2013 at 10:38 AM, Mark S. Miller <erights@google.com> wrote:

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

Apologies for perhaps over-broad language, and not fight is intended
(obviously...I'm part of both the W3C and TC39 worlds).

That said, the reality is this: what DOM/CSSOM does is going to happen
first, and a result, it's not necessary for the CSS WG to particularly pay
attention to the controversies that are outlined below. They are important,
and will get settled, but the high order bit is that TC39 has agreed to be
compatible and that the DOM spec is canonical.


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