| 03:28 | <sirisian> | You're completely right. Writing up some examples and running into design issues, so I'll continue thinking about it. |
| 03:31 | <sirisian> | emilio: Oh your name sounded familiar. I was just reading your comment the other day when I made this issue: https://github.com/WICG/webcomponents/issues/1038 |
| 06:55 | <sirisian> | https://github.com/sirisian/slottedelements I think this would work for me. Any less ad-hoc solutions? |
| 10:28 | <Ms2ger> | Looking at delta traverse from #6315, if delta is zero, should we run both step 3 "reload" and step 4 "Traverse the history by a delta"? Before #6315, we seem to have had an early return there. CC Domenic Jake Archibald |
| 10:30 | <Domenic> | Looking at delta traverse from #6315, if delta is zero, should we run both step 3 "reload" and step 4 "Traverse the history by a delta"? Before #6315, we seem to have had an early return there. CC Domenic Jake Archibald |
| 10:30 | <Ms2ger> | Will do, thx |
| 10:35 | <Ms2ger> | https://github.com/whatwg/html/pull/9980 |
| 21:59 | <akaster> | In the transfer steps for message ports (https://html.spec.whatwg.org/multipage/web-messaging.html#message-ports:transfer-steps), is there any actual implementation steps intended for step 2 to transfer a task source? My interpretation at the moment is that all this is saying is that on the other end, when you reconstitute the message port, to make sure to set up a task source for it. Or is it possible that there are pending messages at the time you transfer the message port, and those messages should be stashed and delivered to JavaScript on the other side? |
| 22:00 | <akaster> | Does anyone actually write code like that? postMessage to a message port, and then transfer the message port, expecting the message to be received on the other end? |