| 00:05 | <rniwa> | have we gotten rid of window.find? |
| 06:37 | <annevk> | wycats: it's happening https://github.com/whatwg/html/issues/1840 |
| 06:37 | <annevk> | wycats: you remember bringing this up three years ago? |
| 07:42 | <annevk> | jyasskin: I raised a couple Houdini issues around the event loop thing |
| 07:48 | <jyasskin> | annevk: Cool. |
| 08:28 | <tobie> | heycam|away: any reasons why we have: ReadWriteSetlike → SetlikeRest in the grammar? http://heycam.github.io/webidl/#prod-ReadWriteSetlike |
| 08:28 | heycam | looks |
| 08:28 | <tobie> | Same for http://heycam.github.io/webidl/#prod-ReadWriteMaplike |
| 08:30 | <tobie> | Same of AttributeNameKeyword |
| 08:31 | <heycam> | tobie: I'm not sure. if you think it's clearer feel free to just use MaplikeRest etc. in its place |
| 08:31 | <heycam> | tobie: though if you look at the definition of InterfaceMember maybe it's nicer to read? |
| 08:31 | <heycam> | http://heycam.github.io/webidl/#prod-InterfaceMember |
| 08:31 | <heycam> | than something with "Rest" in its name |
| 08:33 | <tobie> | readability is a good enough reason. :) |
| 08:33 | <tobie> | heycam: I'd all it SetLike, though |
| 08:34 | <tobie> | s/all/call/ |
| 08:34 | <heycam> | you mean with a capital L? or without the "Rest"? |
| 08:34 | <heycam> | or without the "ReadWrite" |
| 08:35 | <tobie> | the latter, sorry. |
| 08:35 | <heycam> | as you wish :) |
| 08:35 | <tobie> | But I see how that breaks consistency with ReadWriteAttributes. |
| 08:36 | <tobie> | heycam: I wanted to know if there was a reasoning behind this. Seems there is. I'll send a PR if I suddenly become strongly opinionated about why it should be simplified. |
| 08:37 | <heycam> | tobie: ok |
| 08:37 | <tobie> | heycam: thanks for the explanations. |
| 08:37 | <heycam> | np |
| 09:56 | <annevk> | jyasskin: the other thing with threads and lifetime is that keeping them alive for the duration of the system allows storing things in variables and being available in the next task/message/job/thingy |
| 09:56 | <annevk> | jyasskin: e.g., for a shared worker manager thread, that's a necessity |
| 13:35 | <annevk> | zcorpan: I think https://github.com/whatwg/html/pull/1790 is good to land now |
| 13:37 | <zcorpan> | annevk: ok thanks |
| 14:40 | <annevk> | Domenic: https://github.com/whatwg/html/commit/cf0355d7e0e229b98f7fbd51b8c7608010c787f5 regressed setting name / constructor url on the SharedWorkerGlobalScope object |
| 14:40 | <annevk> | Domenic: there's basically nothing doing that at the moment |
| 14:40 | <annevk> | Domenic: and I'm not sure how to best bring it back |
| 14:41 | <annevk> | Domenic: I found this because in https://github.com/whatwg/html/pull/1782 I identified the need for a third field on that object, constructor origin, and couldn't figure out where we'd actually set it |
| 15:01 | <kochi> | annevk: thanks for the review, will update the fullscreen PR shortly. |
| 15:01 | <annevk> | kochi: ta, seems done now |
| 15:02 | <annevk> | kochi: might be able to land it later |
| 15:03 | <kochi> | annevk: yeah, not in a hurry but for mental sanity for Friday night. |
| 15:03 | <kochi> | :-) |
| 15:04 | <annevk> | kochi: oh wow, are you back home? |
| 15:04 | <annevk> | kochi: hadn't realized yet that it's kinda late in Tokyo |
| 15:04 | <kochi> | annevk: yes, I'm at home :) |
| 15:04 | kochi | is still jet-lagged? |
| 15:05 | <annevk> | hehe |
| 15:06 | Ms2ger | idly wonders how you fly from Lisbon to Tokyo |
| 15:06 | <jgraham> | On a plane? |
| 15:07 | <gsnedders> | yeah, jgraham's answer seems like the right one |
| 15:07 | <gsnedders> | I mean I'm sure you can go by airship |
| 15:07 | <gsnedders> | but… yeah. |
| 15:07 | <gsnedders> | would take a while. |
| 15:07 | <Ms2ger> | Oh, I thought attached to a long-distance duck |
| 15:08 | <jgraham> | No, you can't fly a duck over china in case it gets turned into crisy pancakes |
| 15:09 | <Ms2ger> | Perhaps it would be better to use a flying nun |
| 15:10 | <kochi> | btw, I flew back via CDG (Paris). |
| 15:11 | <Ms2ger> | I see |
| 15:34 | <jyasskin> | annevk: Does the storage need to be associated with the thread, or can we say that the shared worker manager has such-and-such state, including a thread? |
| 15:54 | <annevk> | jyasskin: could work too |
| 15:55 | <annevk> | jyasskin: would remove need for named threads |
| 15:55 | <jyasskin> | annevk: I did realize that we want each variable to live on a particular thread, to avoid races in updating the variables. |
| 15:56 | <annevk> | jyasskin: yeah, no cross access |
| 15:56 | <jyasskin> | I'd probably want a "bluetooth communication thread" that doesn't have any particular state, but I can just say "The <dfn>bluetooth communication thread</dfn> is a <a>thread</a>." |
| 15:59 | <annevk> | Yeah |
| 15:59 | <annevk> | Associating state with a thread seems better |
| 15:59 | <annevk> | Could make it similar to internal slot dfns of objects |
| 16:47 | <wycats> | annevk yes |
| 17:46 | <jsbell> | jgraham: is http://hoppipolla.co.uk/410/results.db.gz something you would have generated? |
| 17:46 | <jgraham> | jsbell: It is |
| 17:48 | <jsbell> | jgraham: do you know what version of Chrome was used? |
| 17:49 | <jgraham> | jsbell: The one on my machine at the time I guess |
| 17:49 | <jgraham> | It was not generated in a very careful way |
| 17:50 | <jgraham> | I currently have Version 53.0.2774.3 dev (64-bit) so something before that |
| 17:50 | <jsbell> | jgraham: cool - yeah it looks like "not the current one" based on particular failures, but I wanted to confirm |
| 17:53 | <jgraham> | (I don't know how out of date that is or whether my chrome updates broke at some point) |
| 17:54 | <jsbell> | 53 is current |
| 19:20 | <JonathanNeal> | I just noticed that document.querySelectorAll('a').forEach is in Chrome and Safari. When did that happen? |
| 19:26 | <TabAtkins> | Dont' know when, but it's defined due to it being iterable in WebIDL: https://dom.spec.whatwg.org/#nodelist https://heycam.github.io/webidl/#idl-iterable |
| 19:30 | <JonathanNeal> | That’s pretty interesting. I’ve never seen code leveraging that, polyfills for Firefox, or anything talking about it. |
| 19:42 | <gsnedders> | It also conviently avoids all the breakage we saw when we tried to make it have Array.prototype on its prototype chain |
| 20:09 | <TabAtkins> | We're unfortunately still missing the ability to map over it, but at least you can easily cast to an Array now - [...document.querySelectorAll("a")].map(...) |
| 21:30 | <jyasskin> | Is there any interest in adding a second level of error types to DOMException? e.g. bluetooth.requestDevice() returns a NotFoundError for several conditions that result in the user canceling the chooser. However, a site might want to give the user more help and so might want to know if the user canceled because the system doesn't support bluetooth, there |
| 21:30 | <jyasskin> | were no devices, or because they changed their mind. |
| 21:36 | <jsbell> | jyasskin: at TPAC we discussed adding .details to error (in webidl it'd be an "any") |
| 21:36 | <jsbell> | jyasskin: Domenic was going to follow up on that I think... ? |
| 21:37 | <jyasskin> | jsbell: Mhhmm. Would there be guidelines on what details should contain? Or is it just whatever the dispatching spec wants? |
| 21:37 | <jsbell> | the latter |
| 21:41 | <jyasskin> | 'k |
| 22:07 | <BMMJJ> | hello |
| 22:07 | <BMMJJ> | eveyone |
| 22:08 | <BMMJJ> | is this a https://html5.validator.nu help chat ? |
| 22:13 | <BMMJJ> | or w3c |
| 23:34 | <jyasskin> | Domenic / bz: Is the paragraph at http://heycam.github.io/webidl/#ref-for-dfn-dictionary-member-5 correct? It seems to constrain dictionary member types to disallow "SomeDictionary?". |