| 00:03 | <Domenic> | Yeah, it's a good point that the prototype mechanism is not in use for Window and a couple other things (e.g. Location's properties) |
| 00:03 | <Domenic> | You could still do something like "Window's close() method" or "Window: close() method" |
| 00:04 | <Domenic> | But it would indeed be a bit different, as its every instance of Window having its own individual close() method, not Window.prototype sharing it between all of them |
| 01:43 | <MikeSmith> | Domenic: yeah as far as documenting it, it doesn’t fit neatly with other documentation |
| 01:45 | <MikeSmith> | but maybe the difference is not something that matters in practice to developers, so not worth bending over backwards in the documentation to be very precise about it |
| 01:46 | <MikeSmith> | I guess writing good documentation for web-platform features can be as difficult as writing good specs for them |
| 03:48 | <annevk> | Not possible to get multiple instances though |
| 03:54 | <MikeSmith> | right |
| 03:56 | <Domenic> | You can get multiple instances... e.g. iframe.contentWindow |
| 03:57 | <Domenic> | (Yes, it's a WindowProxy, but it transparently passes through Window properties in the same-origin case.) |
| 04:02 | <MikeSmith> | so that’s a nice concrete case to look at the MDN docs for |
| 04:03 | <MikeSmith> | https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/contentWindow |
| 04:03 | <MikeSmith> | > This attribute is read-only, but its properties can be manipulated like the global Window object. |
| 04:06 | <MikeSmith> | that seems to kind of assume the reader already knows that iframe elements have a separate Window instance |
| 04:07 | <MikeSmith> | which is not really clearly stated even in https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe |
| 04:08 | <MikeSmith> | but I guess you learn that quickly if you ever try to actually do anything with an iframe from code |
| 08:05 | <annevk> | rniwa: if capture listeners, then bubble listeners is not web-compatible, I think if we want to avoid detection of shadow trees, we'd need to keep the current spec |
| 08:05 | <annevk> | rniwa: really appreciate that detailed write-up on your composedPath() patch btw |
| 08:07 | <rniwa> | annevk: yeah, we'd see. |
| 08:08 | <rniwa> | annevk: haha, the algorithm is so clever i would have filed a patent if it weren't for a spec'ed text. |
| 08:08 | <rniwa> | annevk: but once you see it, you can't unsee it. it's so simple! |
| 08:09 | <annevk> | rniwa: yeah, just need to translate it to spec text now |
| 08:16 | <rniwa> | annevk: I do have a webkit patch for the event listener now: https://bugs.webkit.org/show_bug.cgi?id=174288 |
| 08:16 | <rniwa> | annevk: so we'll see how it goes. |
| 08:17 | <annevk> | thanks, hoping for the best |
| 08:18 | <annevk> | rniwa: did you consider combining the composedPath() thing with the bit you need to hide window.event from shadow trees? |
| 08:18 | <annevk> | rniwa: e.g., depth +2 for closed and +1 for open shadow trees |
| 08:18 | <annevk> | anyway, prolly keeping them as separate bits in the spec |
| 08:19 | <rniwa> | annevk: oh, we could do that but it's probably cleaner as two separate things |
| 08:20 | <annevk> | Yeah, I got too excited there |
| 12:50 | <annevk> | Making a patch for that was still rather involved |
| 16:03 | <JakeA> | annevk: Any idea who should I talk to at Moz about interest in https://wicg.github.io/background-fetch/? |
| 16:22 | <Domenic> | MikeSmith: annevk: did we have a plan for the "impacts documentation" label? E.g. are we supposed to ping some MDN folks, or are they watching the label, or...? |
| 16:22 | <Domenic> | About to merge https://github.com/whatwg/html/pull/3829 |
| 16:24 | <annevk> | JakeA: I'm gonna nominate mdaly and asuth (both @mozilla.com) |
| 16:24 | <annevk> | JakeA: you can copy me I suppose |
| 16:24 | <annevk> | Domenic: https://github.com/whatwg/meta/pull/89 |
| 16:24 | <JakeA> | Ta! |
| 16:25 | <Domenic> | annevk: OK, so nothing for us to do necessarily |
| 16:25 | <annevk> | Domenic: no, I guess it remains to be seen if it's helping |
| 16:35 | <MikeSmith> | Domenic: I watch that label at least, and I can let other people on #mdn know about specific PRs like https://github.com/whatwg/html/pull/3829 |
| 16:38 | <Domenic> | Awesome, ok. |
| 16:43 | <zcorpan> | MikeSmith: should we have a bot to report issues for mdn when the label is added? |
| 16:43 | <MikeSmith> | zcorpan: that would be good yeah |
| 17:59 | <Domenic> | devsnek: what are your plans for the async iterable streams PR? |
| 17:59 | <devsnek> | Domenic: do whatever those comments say |
| 17:59 | <Domenic> | :) |
| 17:59 | <Domenic> | Thoughts on implementation/tests? |
| 17:59 | <devsnek> | oh yeah that too lol |
| 18:00 | <devsnek> | i can bang out an impl but i'm absolutely terrible at tests |
| 18:00 | <Domenic> | They're not too bad I promise |
| 18:00 | <Domenic> | And they help a lot with all these edge cases people are pointing out |
| 18:00 | zcorpan | wakes up |
| 18:00 | <zcorpan> | anyone want help with tests? |
| 18:01 | <Domenic> | Haha. This would be for https://github.com/whatwg/streams/pull/954 |
| 18:01 | <devsnek> | i'm gonna get to it again this weekend so eh you can go back to sleep :P |
| 18:02 | <zcorpan> | Domenic: should i add Streams for 2019? |
| 18:02 | <Domenic> | zcorpan: probably not, I think we've got a decent handle on things, just sussing out whether devsnek's up for extending his first-time contribution past the spec into tests as well, or whether the editors should help :) |
| 18:03 | <zcorpan> | okie |
| 18:03 | <devsnek> | i can write some basic tests, i'm just really bad at imagining how people will misuse things |
| 18:04 | <zcorpan> | I think I'm not terrible at that, would be happy to help whip up a list of interesting cases to test |
| 18:04 | <Domenic> | Maybe we can work out a test plan together on the issue |
| 18:04 | <Domenic> | Yeah |
| 18:04 | <devsnek> | what if people just never made bugs |
| 18:06 | <zcorpan> | https://i.imgflip.com/wu987.jpg |
| 18:13 | <zcorpan> | I'm not too familiar with testing JS stuff, but https://github.com/tc39/test262/search?q=asynciterator&unscoped_q=asynciterator might be a good start to look at. I've also asked my colleagues who have written tests for async iterators to chime in |
| 18:14 | <devsnek> | thx |
| 18:33 | <Domenic> | Alrighty, I made https://github.com/whatwg/streams/pull/954#issuecomment-421107013 , we'll see what people say |
| 18:36 | <devsnek> | Domenic: you're too pro |
| 19:15 | <zcorpan> | Domenic: why isn't streams a tc39 spec btw? |
| 19:18 | <Domenic> | zcorpan: tc39's working mode is not very compatible with streams. Ask me more offline :) |
| 21:31 | <MikeSmith> | Domenic: about the “impacts documentation” label, sheppy points out there’s no way to subscribe to github labels (so can’t get notifications that are filtered to just that label) |
| 21:32 | <MikeSmith> | I guess that’s part of the reaason we have teams for some other cases where we want to make sure specific set of people get notified |
| 21:32 | <MikeSmith> | so maybe we should add a “documentation” team? |
| 21:53 | <Domenic> | +1, sounds good to me |
| 22:00 | <MikeSmith> | Domenic: thanks |
