| 09:26 | <annevk> | nox: maybe you need to run bikeshed update? |
| 09:26 | <annevk> | nox: I don't get fatal errors here |
| 09:26 | <annevk> | nox: I do have two warnings I need to remove at some point |
| 09:48 | <nox> | annevk: Still the same after bikeshed update. |
| 09:48 | <annevk> | Maybe I need to run bikeshed update |
| 09:49 | <nox> | Ah ah. |
| 09:49 | <nox> | annevk: Did you take a look at <https://github.com/whatwg/dom/issues/60>;? |
| 09:51 | <annevk> | nox: it shouldn't matter |
| 09:51 | <annevk> | nox: it'll only matter if you implement synchronous notifications on top for internal usage |
| 09:52 | <annevk> | nox: e.g. to implement "iframe removed from document" |
| 09:52 | <nox> | annevk: That's what I gathered, but in Servo we strive to make the code look as the spec states and I do have to queue the mutation record after the mutation there (because the machinery is used for things that are not related to queuing of mutation records). |
| 09:53 | <nox> | So I was wary of inversing the steps. |
| 09:53 | <annevk> | What's the machinery used for? |
| 09:53 | <nox> | annevk: Updating Node.childNodes. |
| 09:54 | <nox> | And other things, like updating Document.title |
| 09:54 | <annevk> | I still don't get any errors |
| 09:54 | <nox> | Weird. |
| 09:54 | <annevk> | Updating document.title? That should be a lazy getter... |
| 09:55 | <nox> | annevk: How do you update the window's title |
| 09:56 | <annevk> | I think for that kind of stuff you'd like to just observe the title element, but I'm not entirely sure what would be the best |
| 09:58 | <nox> | Well, consider I'm observing it, |
| 09:58 | <nox> | I would have to allocate an actual mutation observer and whatnot, so instead I use the underlaying infrastructure for this, |
| 09:58 | <annevk> | I wonder if TabAtkins could look into your bikeshed problem... I wonder what's different between our setups |
| 09:59 | <nox> | but if the mutation didn't happen yet, that means I can't just get the text content of <title> and have to work with removedNodes and addedNodes. |
| 09:59 | <nox> | annevk: Mmmh, I don't have an error anymore, must have done something wrong. |
| 10:00 | <nox> | I still think this ordering inconsistency should not be there, if only just to be consistent. |
| 10:01 | <nox> | And it bothers me when propagating the mutation to Node.childNodes. |
| 10:04 | <nox> | annevk: When making a PR, should I submit changes to the HTML file too? |
| 10:05 | <annevk> | nox: yeah, if you can run bikeshed that'd make integration easier |
| 10:05 | <annevk> | nox: I guess I should mention something like that in the README |
| 10:05 | <nox> | Ok, it made a lot of changes, that's why I ask. |
| 10:06 | <nox> | annevk: Running bikeshed on master says: 1 file changed, 771 insertions(+), 773 deletions(-) |
| 10:07 | <annevk> | nox: seems okay |
| 10:14 | <nox> | annevk: Err, I think https://github.com/whatwg/dom/issues/59 is still not the right fix. |
| 10:14 | <nox> | annevk: previousSibling will be wrong if node == child, AFAICT. |
| 10:15 | <annevk> | reopened |
| 10:15 | <annevk> | will look at it later |
| 10:16 | <nox> | Ok. |
| 14:13 | <annevk> | wanderview: so respondWith() is kind of a racy way to get a Response to be read... |
| 14:14 | <annevk> | wanderview: e.g. if you pass a Response to both respondWith() and something else that takes a promise for a Response (do we have anything like that?) it's unclear which will win... |
| 16:43 | <annevk> | What's the point of having https://github.com/orgs/whatwg/teams/contributors ? |
| 16:56 | <annevk> | I enabled third-party restrictions for the WHATWG repo, let me know if I broke anything |
| 16:57 | <boogyman> | annevk: that url is not public (inot sure if that's helpful feedback) |
| 16:59 | <annevk> | boogyman: thanks, but doesn't matter |
| 18:03 | <Domenic> | botie: tell annevk I think contributors was designed so I could assign bikeshed-related issues to tabatkins |
| 18:03 | <botie> | Domenic: what? |
| 18:08 | <TabAtkins> | annevk: There was a problem a day or two ago where the CSSWG specs had cascading failures; that's fixed now. |
| 18:08 | <TabAtkins> | annevk: That temporarily wiped out most of the definitions coming from CSS specs. |
| 18:14 | <TabAtkins> | (Also, now I track what version the repo's data files are, so if I update those and you haven't manually updated in a while, you'll pick up the updated files for free.) |
| 18:47 | <wanderview> | annevk: as far as I know, there is nothing else that takes a Promise<Response> like respondWith() |
| 18:51 | <wanderview> | annevk: and I think I confirmed with bz recently that .respondWith() and .waitUntil() are the first standard webidl we have that takes a promise as an argument (there may be a moz-specific API as well) |
| 18:53 | <annevk> | yeah that seems correct |
| 22:43 | <TabAtkins> | Domenic: The example code in 4.2.2 of the promises guide is actually super confusing. |
| 22:44 | <TabAtkins> | "Run the following in parallel" suggests that the two substeps are meant to race each other in parallel, when that's exactly opposite. |
| 22:45 | <TabAtkins> | I thought the suggestion was to put the async section at the end, with an explicit "return foo, and continue the rest of this algorithm async" |