- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 28 May 2014 12:44:35 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "www-style@w3.org" <www-style@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
On Wed, May 28, 2014 at 3:29 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, May 27, 2014 at 9:42 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> On Tue, May 27, 2014 at 12:35 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >>> Well, you're changing the status but can that actually be observed >>> somehow? If not, why are you changing the status? Changing the status >>> of something and making that observable typically requires queuing a >>> task, unless you use a promise, but in that case you can only change >>> the status once, by resolving the promise. >> >> I'm not sure what you're talking about here, so I've pinged you on >> IRC. Hopefully we can resolve it better there. > > Okay. If people want to follow along, > http://krijnhoetmer.nl/irc-logs/whatwg/20140527#l-668 and > http://krijnhoetmer.nl/irc-logs/whatwg/20140528 The upshot is that async portions of algos can run at any time, and may be run in separate threads/processes, so if you just make an observable change, like I'm currently doing, it might happen in the middle of a block of author code, violating JS's run-to-completion semantics. Instead, any observable changes have to be made in a synchronous block that is explicitly queued as a task, so it definitely happens between author blocks. This is now documented on our wiki at <http://wiki.csswg.org/spec/async-algos>, so anyone can reference it the next time they need to write an asynchronous algorithm. >>> Well, you could look at how http://dom.spec.whatwg.org/#concept-throw >>> does it... >> >> I was specifically looking for something other than "remember to check >> this specific spec to see how it does it". ^_^ Like, CSS puts some >> spec-authoring guidance on its wiki >> <http://wiki.csswg.org/spec#coordination-between-specifications>. >> Something similar (even in our wiki - if you don't have an account, >> just send me some guidance and I can add it myself) would be great. > > Well, DOM defines DOMException at the moment so it would be *the* > specification to check for usage. > > And in particular what I pointed you to is exactly what you want to do > here. Reject with a DOMException object whose name is x, message is > some user agent-defined value, and code is set per the table. That's what I want to do, yes, but not what I want to type. Can we add a prose hook somewhere that defines "reject with a FooError exception" as the above? You mention WebIDL maybe doing this, but I'd think it appropriate for DOM to do it too. ~TJ
Received on Wednesday, 28 May 2014 19:45:27 UTC