| 00:16 | <Domenic> | The downside of that is that then we have to keep it implicitly in sync with the close watcher spec text. Maybe we can refactor though... |
| 10:38 | <evilpie> | Someone up for reviewing https://github.com/web-platform-tests/wpt/pull/51827 ? |
| 11:19 | <annevk> | evilpie: you should be able to review that? |
| 11:20 | <annevk> | Anyway, rubber-stamped. |
| 11:21 | <evilpie> | Oh indeed 😂 Thank you Anne. |
| 12:46 | <evilpie> | Ah, I was probably just confused because I can't merge and I forgot that this is not the same permission. |
| 12:53 | <Ms2ger> | evilpie: check your inbox |
| 15:07 | <Luke Warlow> | The downside of that is that then we have to keep it implicitly in sync with the close watcher spec text. Maybe we can refactor though... Do we? In what sense? We fire a cancel event that's always cancellable, and then call close which itself can do anything that's necessary. |
| 22:52 | <Domenic> | It's specifically firing the cancel event and firing the close event which I am not excited about duplicating. If the cancelSteps or closeSteps of https://html.spec.whatwg.org/#set-the-dialog-close-watcher ever get updated (or if we add more steps to https://html.spec.whatwg.org/#close-watcher-request-close , or...) then we'd need to remember to update requestClose(). |