| 11:49 | <annevk> | Anyone here played Broken Age? Such a great little game |
| 14:27 | <annevk> | https://github.com/annevk/live-url-viewer is mostly functioning again and online |
| 14:30 | <MikeSmit1> | annevk: what’s the difference liveview and liveview2 and liveview3? |
| 14:31 | <annevk> | MikeSmit1: the JavaScript ends up showing slightly different things |
| 14:31 | <annevk> | MikeSmit1: this code is all based on something rubys created at one point |
| 14:31 | <annevk> | MikeSmit1: not sure it's the best interface, but at least it now runs on top of a new URL parser |
| 14:33 | <MikeSmit1> | yeah definitely nice to have an implementation to check with that is known to fully conform to the spec |
| 14:38 | <MikeSmith> | annevk: about https://github.com/whatwg/fetch/issues/443, the comment “I really don't understand how people are creating production-quality applications with fetch() as it does not give access to pre-flight responses” I am wondering what the alternative is that he uses for production-quality applications |
| 14:39 | <annevk> | MikeSmith: worth asking |
| 14:41 | <MikeSmith> | well it was a rhetorical question I guess |
| 14:42 | <MikeSmith> | because in the context of the limitation he mention, there is not an alternative on the client side that behaves any differently in that regard |
| 16:11 | <smaug> | setTimeout/Interval callbacks never run in the same task, right? |
| 16:11 | <smaug> | I mean, each callback get their own task |
| 16:48 | <annevk> | smaug: yeah |
| 16:49 | <smaug> | ok, thanks |
| 17:05 | <smaug> | there isn't a concept of "end of task" defined really anywhere, right? |
| 17:05 | <smaug> | should it be defined? |
| 17:05 | <smaug> | IDB uses it |
| 17:06 | <annevk> | smaug: sounds like a bug in IDB |
| 17:07 | <annevk> | smaug: I guess it means to use microtasks or some such? |
| 17:07 | <smaug> | no |
| 17:07 | <smaug> | it clearly tries to use something else |
| 17:09 | <smaug> | "When control is returned to the event loop, the implementation must unset the active flag." and "When transaction is finished, immediately set request’s transaction to null. This must be done in the same task as the task firing the complete or abort event, but after the event has been fired." |
| 17:10 | <smaug> | I guess https://github.com/w3c/IndexedDB/issues/87 is about this |
| 17:10 | <annevk> | Oh it seems they could just restructure the way algorithms work there |
| 17:11 | <annevk> | Since it sounds like the flag is unset before microtasks |
| 17:11 | <smaug> | after microtasks |
| 17:21 | <annevk> | oh, that is fairly magical |
| 17:21 | <annevk> | good times |
| 17:23 | <annevk> | smaug: but if the microtasks run as a result of the event dispatch there's not really an issue I think |
| 17:23 | <annevk> | smaug: because they'd all run at that point and not at the end of the task |
| 17:39 | <annevk> | when you do url.searchParams.forEach(fun) |
| 17:41 | <annevk> | why is fun invoked as if its signature is value, name rather than name, value? |
| 18:14 | <Domenic> | it mirrors arrays |
| 18:14 | <Domenic> | array.forEach((value, index) => ...) |
| 18:38 | <annevk> | Domenic: thanks, makes sense I guess |
| 19:54 | <botond> | TabAtkins: hey, are you around? i have a question about bikeshed |