- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 14 Jan 2014 11:34:09 -0500
- To: Domenic Denicola <domenic@domenicdenicola.com>, Takeshi Yoshino <tyoshino@google.com>, "www-tag@w3.org" <www-tag@w3.org>
- CC: public-webapps <public-webapps@w3.org>
On 1/14/14 10:44 AM, Domenic Denicola wrote: > So maybe we need slightly better phrasing; help appreciated. Maybe the right way to spec this is to simply use two algorithms... Algorithm A has some steps, then says to perform B asynchronously and returns a promise. B has a bunch of steps that end with resolving the promise. That avoids the issue of having steps-after-return and also avoids the issue of the steps of B needing to be indented a level and not clearly separated from the (conceptually separate) steps of A. I think the only issue with the two-algorithm setup might be http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigating-across-documents in which there is actually a goto from what I call B above (in http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-redirect-step ) to a step that is in A (http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#navigate-fragid-step ). I can't say that I'm terribly happy with that setup, though, so I think discouraging it in general is _not_ a bad thing. This seems like too much overhead when B is only a step or two, of course, maybe in those cases inlining it inside a "do these steps async" block is good. -Boris
Received on Tuesday, 14 January 2014 16:34:41 UTC