| 08:20 | <freddy> | https://wiki.whatwg.org/ throws server errors |
| 08:24 | <sideshowbarker> | I wish we’d move all that wiki content to https://github.com/whatwg/whatwg.org/wiki |
| 09:00 | <annevk> | sideshowbarker: making it a bunch of static pages has been proposed before; just needs someone willing to do it |
| 09:00 | <annevk> | And I guess some coordination with GPHemsley |
| 10:06 | <ntim> | annevk: I think I addressed all the comments on https://github.com/whatwg/html/pull/7134 |
| 14:11 | <Domenic> | https://wiki.whatwg.org/ throws server errors |
| 14:20 | <annevk> | ntim: I unresolved some of the comments; I still think it would be good if we could more explicitly share logic with pointer-events:none by having a <dfn> in css3-ui (I'll defer to Domenic as to whether that's blocking or a follow-up issue); and do you know if rniwa has seen this? |
| 14:21 | <annevk> | ntim: seems good otherwise though |
| 14:29 | <ntim> | annevk: huh, I thought I made the change to add the pointer-events link, but I didn't |
| 14:31 | <ntim> | annevk: rniwa is on medical leave :( but the concerns he expressed previously (slowing down performance) aren't relevant to the current implementation. |
| 14:32 | <ntim> | annevk: anyway, I pushed the change to share logic with pointer-events: none, I think this should remove the need for an example now |
| 14:41 | <ntim> | Domenic: Hey, has there been any progress on the Chrome side regarding this issue? https://github.com/whatwg/html/pull/4184 |
| 14:42 | <Domenic> | ntim: There has been some discussion. One thing that would help move it forward is if we had commitment from Firefox and Safari to change all their browser dialogs (e.g. edit/add bookmark, about, etc.) to use focus-the-dialog instead of focus-the-first-focusable-control. |
| 14:44 | <ntim> | Domenic: do you have any example of Safari dialog that does this? |
| 14:46 | <Domenic> | In some testing so far it looks like on Macs nothing is focusable in most dialogs... that's interesting. |
| 14:48 | <Domenic> | ntim: Bookmarks > Add bookmark is one example that focuses the first focusable control |
| 14:49 | <Domenic> | File > Export as PDF is the same |
| 14:49 | <annevk> | ntim: rniwa's concern wasn't about perf I thought, but the model |
| 14:49 | <ntim> | Domenic: the point here is not all <dialog>s will be used for this usecase, so forcing it for all dialogs is counterintuitive |
| 14:49 | <Domenic> | File > Print is the same |
| 14:49 | <annevk> | ntim: in particular what type of tree ought to be used, but I guess it's kinda moot if it's going to be pointer-events based |
| 14:50 | <Domenic> | ntim: That is where I disagree. If you are using <dialog> for something that is not a dialog, you are violating the spec, and should use e.g. the proposed <popup>, or a <div>. |
| 14:50 | <ntim> | A ToS <dialog> is a valid usecase for <dialog> no? |
| 14:50 | <Domenic> | If Safari believes that all dialogs should focus the dialog itself, then it'd help if they applied that consistently. But it looks right now like they believe instead dialogs should focus the first focusable control, based on the rest of their product |
| 14:51 | <Domenic> | ntim: Yes, and then you'd make the TOS text scrollable and focusable. (I can find Mac examples of this if you'd like.) |
| 14:51 | <annevk> | Domenic: ntim: the status of that particular issue was that mfreed was going to look into it, iirc |
| 14:52 | <annevk> | And he'd ping that issue with an update on behalf of Chrome |
| 14:52 | <Domenic> | Yep, I'm just relaying what has come out in our internal discussions in Chrome |
| 14:59 | <annevk> | I see, I'm not sure what that means for us. I think the one thing that might be acceptable is if there was some kind of override available whereby the dialog would be focused. emilio might recall better. But we might also ship with a spec violation... I think we did look at some of our internal dialogs and weren't too impressed with those 🙂 |
| 14:59 | <Domenic> | Yeah, I'd encourage you to talk to e.g. your UI team, and ask them what they think of changing Edit/Add Bookmark to focus the dialog instead of the bookmark name field. |
| 15:04 | <Domenic> | (Or your installer team, to ask if the TOS page in your installer dialog should focus the dialog instead of the TOS text box... although I don't know if Safari has an installer.) |
| 15:04 | <ntim> | Domenic: I'm not sure if all web developers know how to make paragraphs focusable, the more likely thing that will happen in this case is that focus will go on a random link in the ToS text, on some random control after |
| 15:05 | <ntim> | or if that's the first thing that they'll think intuitively of |
| 15:07 | <Domenic> | Yeah, it does require a small amount of effort to get good behavior in the TOS-dialog type case. My opinion is that is an OK ask, compared to requiring every other non-TOS-type dialog to opt in to (IMO correct) behavior. |
| 15:08 | <Domenic> | After all, there is usually only one TOS dialog per app, which the user sees once. They see edit/confirm/etc. type dialogs many times per app |
| 15:08 | <Domenic> | Mason was thinking of trying to gather some data on the prevalence of various types of dialogs, to weigh the potential harm of either default in the cases where developers don't put in enough effort to do the right thing, but I imagine that's a lot of manual work. |
| 15:10 | <ntim> | The argument from most screen reader users is that <dialog> traps the focus on itself, like a web document itself does, so matching the behavior of a web document is best since you can't really predict what will be put in. |
| 15:10 | <ntim> | (well modal dialogs trap the focus) |
| 15:10 | <Domenic> | I mean, you can predict? It'll be the first focusable control, like all the other dialogs your browser provides. |
| 15:11 | <Domenic> | Again, if we believe that we should stop focusing the first focusable control for all browser-provided dialogs, then definitely we should align web content with that. That would make it easy. But it's saying that when you use the browser, you experience two types of dialogs: Apple/Mozilla/Google dialogs, and web-dialogs, that is not so great. |
| 15:12 | <Domenic> | (Browser modal dialogs also trap focus in themselves, so focus-trapping of <dialog> doesn't really change the equation.) |
| 15:13 | <ntim> | Also, would you consider a "Enable notifications for this website?" non-modal dialog a valid use case for <dialog>? |
| 15:13 | <ntim> | Enable notifications for this website? [OK] [Not now] |
| 15:13 | <ntim> | This isn't transient, so I suspect <popup> would be inappropriate here |
| 15:14 | <ntim> | In this case I don't think it'd be particularly pleasant UX to make it focus [OK] by default |
| 15:16 | <Domenic> | That's an interesting one, yeah. I think it's a <popup> in Chrome and a <div> in Firefox, roughly speaking, but who knows if that's intentional. It seems like a legit thing to be a <dialog>, but you'd want to put autofocus="" on the "Not now" button if you were being a good citizen. |
| 15:17 | <ntim> | I don't think you can expect websites which display these kinds of dialogs to be good citizens 😅 |
| 15:17 | <ntim> | there are legit websites displaying these in a non transient way |
| 15:17 | <Domenic> | (E.g. in Chrome it has popup's "light dismiss" behavior, but in Firefox it's persistent and nothing is focusable.) |
| 15:18 | <Domenic> | For sure. But our goal is not to protect against bad citizens; they will just do autofocus="" on the OK button. |
| 15:18 | <Domenic> | This is starting to verge on a trickier issue of the OK/Cancel ordering across Mac/Windows+Linux, and how maybe the web should help with that :) |
| 15:18 | <ntim> | I suspect things like this will use non-modal <dialog>s |
| 15:19 | <ntim> | and not <popup> |
| 15:19 | <ntim> | (you can't dismiss this in Element) |
| 15:19 | <Domenic> | Yeah. Non-modal dialogs don't even focus trap so it's a very different scenario. |
| 15:19 | <Domenic> | I think that has light-dismiss behavior so is a <popup>? Not sure. |
| 15:20 | <ntim> | the only way to dismiss this is to click "Later" or "Verify", clicking outside doesn't work |
| 15:20 | <Domenic> | Ah OK, dialog then for sure |
| 15:21 | <Domenic> | I admit I haven't looked much at non-modal dialogs. Maybe we do want a different behavior for them. |
| 15:21 | <Domenic> | Since they are part of the overall focus order of the page instead of having a focus trap |
| 15:22 | <ntim> | I suspect lots of websites will use non-modal dialogs for this type of thing, e.g. enabling notifications (requiring users to take action inside the <dialog>), etc. |
| 15:22 | <ntim> | or subscribe to our newsletter, etc. |
| 15:23 | <ntim> | I think it'd be evil UX to force the first focusable control (e.g. [Yes]), but maybe some websites won't mind, because they want the user to take action |
| 15:25 | <Domenic> | I mean "evil" is a bit strong of a word for "the user has to press tab one less time" / "the website focused the control it wanted to focus". We can't protect against truly "evil" websites unless we remove autofocus=""/element.focus(). |
| 15:25 | <Domenic> | I am more compelled by the idea that non-modal dialogs are different because they are part of the overall tab order |
| 15:25 | <Domenic> | Which is a setup, I believe, very different from native, where non-modal dialogs still do focus trapping |
| 15:26 | <ntim> | Yep, I believe showModal() is what has been focused on so far |
| 15:27 | <Domenic> | Personally I would be comfortable with show() focusing the dialog and showModal() focusing the first focusable control. (With autofocus="" providing an override in both cases.) |
| 15:33 | <ntim> | There may be cases where the first focusable control isn't necessarily something important too, e.g. a search box |
| 15:34 | <ntim> | anyway, I think a11y experts are probably more well-versed on this topic than I am |
| 15:35 | ntim | is just implementing <dialog> in WebKit |
| 15:36 | <ntim> | Taking in account what screen reader users will experience is important |
| 15:40 | <Domenic> | Yeah. That is part of my concern as well; if screen reader users experience one thing for edit browser bookmark and another for edit Matrix channel name, that seems problematic. I think that is also something Mason was going to ask about. |
| 15:42 | <ntim> | I think what we can both agree on, is that this behavior is problematic for non-modal dialogs |
| 16:35 | <emilio> | FWIW those use HTML <dialog>, so the behavior will change if/when we change it |
| 16:36 | <Domenic> | Great to hear! I'm still curious what the UI folks think about the change you're making for them :) |
| 16:51 | <Domenic> | Oh, interesting historical background: non-modal dialogs used to behave like they do on native, where they focus-trap but you can manually escape their "control group". But it was never implemented; instead we just got focus trapping for free in the modal case via inerting everything, and never implemented anything for the non-modal case. So we removed control groups from the spec. https://github.com/whatwg/html/pull/3647 . This helps explain why non-modal dialogs are in a bit of a weird space today. |
| 22:15 | <mfreed> | annevk: just a quick update from me. As Domenic mentioned, we've been internally discussing this issue to try to come to a consensus. That process is still playing out, so I apologize for the delay posting publicly. But there is definitely motion behind the scenes, and I haven't forgotten about the issue. Thanks! |