| 06:16 | <annevk> | MikeSmith: yes, "don't monkey patch" |
| 06:16 | <annevk> | MikeSmith: I think there might be an issue open for this against HTML |
| 06:16 | <MikeSmith> | ok |
| 06:16 | <annevk> | MikeSmith: https://github.com/whatwg/html/issues/5204 |
| 06:19 | <annevk> | MikeSmith: and filed https://github.com/w3ctag/design-principles/issues/184 |
| 06:20 | MikeSmith | loosk |
| 06:20 | <MikeSmith> | ah cool |
| 06:20 | <MikeSmith> | thanks |
| 06:22 | <MikeSmith> | in other news, the UI Events spec doesn’t seem to actually define any event handlers named “onfocusin” and “onfocusout” (despite defining “focusin” and “focusout” events) |
| 06:24 | <MikeSmith> | and blink and gecko don’t seem to have “onfocusin” and “onfocusout” event handlers, though webkit does |
| 06:25 | <annevk> | MikeSmith: that has an issue too |
| 06:25 | <MikeSmith> | aha |
| 06:25 | <annevk> | MikeSmith: (UI Events is a mess in general) |
| 06:25 | <MikeSmith> | yeah |
| 06:25 | <MikeSmith> | and I vaguely recall having asked about this before |
| 06:25 | <annevk> | MikeSmith: the whole lot of focus events ought to be moved to HTML |
| 06:25 | <MikeSmith> | right |
| 06:25 | <MikeSmith> | that would be nice |
| 06:25 | <MikeSmith> | I vote for that |
| 06:26 | <annevk> | If we have focusin/focusout we should also have the event handlers |
| 06:26 | <MikeSmith> | yeah |
| 06:27 | <MikeSmith> | anyway, found https://github.com/whatwg/html/issues/4542 Should `onfocusin`/`onfocusout` IDL attributes be added? |
| 06:27 | <MikeSmith> | and https://github.com/whatwg/html/issues/3514 Define all focus events |
| 08:50 | <annevk> | MikeSmith: https://github.com/w3c/webappsec-feature-policy/issues/359#issuecomment-627845363 wants another tech writer opinion 🙂 |
| 10:12 | <annevk> | ta |
| 15:04 | <Domenic> | Wow I was unsure on permission vs. permissions but that "right policy" argument has me solidly convinced. |
| 16:08 | <annevk> | Domenic: quick check, is the default revert commit message fine for the title or did we have a different style, e.g., "Revert: ..."? |
| 16:09 | <annevk> | I should probably include the information from OP in the body for clarity |
| 16:09 | <Domenic> | Default is what I remember |
| 16:09 | <annevk> | k |
| 16:09 | <annevk> | And yeah, I regret not testing that one, that was dumb |
| 16:27 | <annevk> | Domenic: I should have looked at mgiuca's branch earlier, that has an approach that probably works |
| 16:27 | <Domenic> | Nice |
| 16:34 | <Domenic> | annevk: can you use spec-factory to give Infra the latest makefile? |
| 16:35 | <annevk> | Hmm, it should have created a PR |
| 16:35 | <annevk> | Domenic: https://github.com/whatwg/infra/pull/301 |
| 16:36 | <annevk> | I guess I could run it again though I'm worried that some repos that haven't merged it will get a duplicate |
| 16:36 | <Domenic> | It got outdated hmm |
| 16:37 | <annevk> | yeah that's weird |
| 16:38 | <Domenic> | The GitHub button seemed to work |
| 16:41 | <annevk> | ooh |
| 16:41 | <annevk> | i think this is my fault |
| 16:41 | <annevk> | let me fix something |
| 16:42 | <annevk> | I had enabled "Require branches to be up to date before merging " in a few places without realizing what a pain it was |
| 16:42 | <Domenic> | Ah yeah |
| 16:42 | <annevk> | forgot to disable it here |
| 21:29 | <saber1> | Domenic: I have a testcase https://mozilla.seanfeng.dev/files/testcase-fullscreen-dialog.html, clicks the div makes the div fullscreen, and it'll show a modal dialog afterwords. At this point, press `escape` will exit the fullscreen first in Chrome. Would you consider this a Chrome bug? I think it violate the `Canceling dialogs` section |
| 21:31 | <Domenic> | saber1: I don't think it violates the spec, as the Canceling dialogs section is intentionally vague and UI affordances like "what does Esc do" are really up to each browser. But I think I would personally prefer to escape out of all dialogs first before escaping out of fullscreen; I'd be curious what our UX/security folks think. |
| 21:32 | <Domenic> | I guess it would be bad if you could pop up a ton of modal dialogs and thus prevent the user from exiting fullscreen until they pressed Esc a thousand times? |
| 21:39 | <saber1> | Domenic: I see...What I was thinking was, if the `escape` key is the user interface to cancel the dialog, since the document is blocked by the modal dialog, pressing this key should cancel the dialog. But yeah I see your point, I think this is fine |