| 11:55 | <annevk> | I'm not sure I'll have the time today, still have a massive backlog somehow |
| 14:06 | <annevk> | Domenic: so it would really help if someone else reviewed the imperative shadow DOM APIs too |
| 14:06 | <annevk> | I don't get the impression rniwa looked at it in detail, but I might have missed something |
| 14:13 | <annevk> | Domenic: isn't https://github.com/w3c/webcomponents/issues/871#issuecomment-675863258 showing the diff? |
| 14:31 | <Domenic> | annevk: that's a proposed test case, but not a spec diff. |
| 14:32 | <Domenic> | I don't believe there's a spec diff that would change the result of that; certainly not the one suggested upthread. |
| 14:32 | <Domenic> | annevk: I can do a second pass on imperative shadow DOM once you've done yours |
| 14:33 | <annevk> | Domenic: I just did again on the DOM side |
| 14:33 | <annevk> | Domenic: I thought making attachInternals check the custom element state would do the trick |
| 14:33 | <annevk> | That is something HTMLConstructor modifies |
| 14:34 | <Domenic> | annevk: yes, but it modifies it at the same time as the element definition comes into being, which is already checked. |
| 14:36 | <annevk> | Doesn't the definition come into being when you invoke define()? |
| 14:38 | <annevk> | Looking at the algorithms it definitely seems like you could get to an element that doesn't have its custom element state changed from script when define() is invoked |
| 14:39 | <Domenic> | Hmm, well, I might be wrong; looking forward to seeing the proposal. |
| 14:42 | <annevk> | https://github.com/whatwg/infra/issues/320#issuecomment-676736001 sounds pretty neat |
| 14:49 | <annevk> | It's taken a bit of time to get here, but I just landed a contribution from MikeSmith \o/ |
| 14:51 | <Domenic> | Sooo happy |
| 14:54 | <MikeSmith> | this party’s got a double E at the end again 🎉 |
| 14:55 | <MikeSmith> | https://www.youtube.com/watch?v=5opqN7DmGK8 |
| 14:55 | <MikeSmith> | thanks y’all |
| 15:28 | <annevk> | zcorpan: hmm, so I wonder if response.headers.set is messing with the value somehow and if instead we should write out the headers in raw |
| 15:29 | <annevk> | zcorpan: did you look at server responses already? |
| 15:29 | <annevk> | although I'm not sure why that would result in a timeout |
| 15:30 | <annevk> | Oh, maybe that would timeout if the python script ended up throwing |
| 20:52 | <zcorpan> | annevk: yes, the server response looks ok. no error, \t comes through as 0x09 |