18:01:48 RRSAgent has joined #openui 18:01:48 logging to https://www.w3.org/2022/10/06-openui-irc 18:01:52 tbondwilkinson has joined #openui 18:02:24 Zakim has joined #openui 18:02:31 present+ 18:02:33 Zakim, start the meeting 18:02:33 RRSAgent, make logs Public 18:02:34 please title this meeting ("meeting: ..."), hdv 18:03:01 meeting: Open UI Telecon, October 06, 2022 18:03:11 present+ 18:03:12 present+ 18:03:13 present+ 18:03:13 present+ 18:03:18 chair: JonathanNeal 18:03:21 scribe: hdv 18:03:46 present+ 18:03:57 present + 18:04:11 do we have someone to scribe while hdv is sharing? if not, I will try. 18:04:19 hdv: I found a use case for changing styles based on whether selectmenu is open. Seems the CSSWG has resolved to have :open class that would do that 18:04:32 hdv: So we might not need to do anything, mason does this apply to selectmenu? 18:04:34 present+ 18:04:40 thanks, dandclark ! 18:04:44 masonf: I think it does apply. Don't think we would want to do anythign different for selectmenu 18:04:48 Present+ 18:04:51 q+ 18:04:59 sarahhigley_ has joined #openui 18:05:01 masonf: would say out of the box we should support this for too 18:05:11 masonf: prototype wise we would be fine to just support i 18:05:23 q? 18:05:26 s/i/it 18:05:37 ack dandclark 18:05:37 ack dandclark 18:05:39 Proposed resolution: `` supports `:open` as specified in the CSSWG. 18:05:49 +1 18:05:55 +1 🎉 18:05:55 q? 18:05:57 scotto has joined #openui 18:06:01 present+ 18:06:22 RESOLVED: `` supports `:open` as specified in the CSSWG. 18:06:57 Topic: [Popup] Should blur() be a light dismiss trigger? #415 18:06:57 github: https://github.com/openui/open-ui/issues/415 18:07:42 masonf: this is about whether blur is a light dismiss trigger. We talked about this in May and resolved to make it a light dismiss trigger. So as a keyboard user if you TAB out it triggers light dismiss 18:08:10 masonf: for assistive tech users and probably even all users, this could be very frustrating because if you've moved out you wouldn't know where you can from 18:08:26 masonf: one way to solve it could be that Shift+TAB takes you back to the selectmenu that is then magically open 18:09:02 masonf: another way this could be annoying would be if the defaultopen attribute, was used 18:09:26 masonf: so I wonder if our previous resolution was wrong… it may be better if blur is not a light dismiss trigger 18:09:30 q? 18:09:33 q+ 18:10:20 q+ 18:10:22 q? 18:10:23 q? 18:10:32 masonf: also, it would be relatively easy for a developer to add dismiss-on-blur behavior. That isn't the case the other way out, if blur was a default light dismiss trigger, it would be hard to opt out 18:10:55 JonathanNeal: is this a proposal also applicable _after_ the popup has received focus? 18:11:19 masonf: I would like to make this universal… there were some thoughts around maybe that it would only light dismiss on blur in _some_ cases but I would prefer something more univeral 18:11:22 q? 18:11:23 s/univeral/universal 18:11:26 ack JonathanNeal 18:11:28 q+ to ask about the usability/expectations of people who do use tab-out to dismiss, then are confused, maybe try esc, but then how would that associated with a popup that's not focused? 18:12:15 ack scotto 18:13:01 scotto: I'm not opposed to this… but it makes me wonder about a few things. Taking away that light dismiss behavior seems to make auto/manual together… Secondly, as far as assistive tech is concerned… if appropriate role are defined, the boundaries of the popup would be better surfaced. There are mappings that could indicate that something behave as a popup, list, dialog, etc 18:13:27 scotto: I don't disagree there is a potential issue here… but want to make sure we aren't correcting for something that should just be better exposed in the first place 18:14:20 q+ 18:14:24 scotto: if you would just add `popup` attribute to a div, without adding a role, you haven't really done something accessible just yet 18:14:33 q? 18:14:51 masonf: there is still a big difference between auto and manual… for keyboard users Escape will close auto popup but not a manual popup 18:15:44 scotto: good point… one question would be where can someone do the Escape… if I see a popup and I see it hasn't closed, but I have moved away from it, I'll need to go back and close it… basically it all comes down to expectations and what roles are exposed 18:16:01 scotto is making one of the points I was going to bring up 18:16:21 scotto: but if it's like, say, a details/summary but you've made the details part more like a popup, it makes sense that it doesn't dismiss 18:17:09 scotto: if this is well defined and we define popup as something that would close, then it's a matter of people learning the behavior that closing on tabbing out is something a popup does 18:17:11 q? 18:17:22 ack tantek 18:17:22 tantek, you wanted to ask about the usability/expectations of people who do use tab-out to dismiss, then are confused, maybe try esc, but then how would that associated with a 18:17:25 ... popup that's not focused? 18:17:45 tantek: +1 to scotto's point on existing expectations on how tab behaves in these kinds of situations 18:18:15 tantek: the question is, do you need to refocus the popup to escape from it? 18:18:51 tantek: re disclosure triangles, I thought you could have multiple of them, so would escape close multiple or not? 18:19:15 tantek: on a higher level, Escape is used as a way to close things like full screen… is there a higher level analysis that needs to be done? 18:19:34 tantek: I'm not sure if full screen is a popup? 18:20:06 masonf: with the way it is defined now in prototype and spec… hitting Escape anywhere it will close the popup, they behave the same, because they are all in the top layer 18:20:13 masonf: it is implemented as a stack, roughly speaking 18:20:36 masonf: if you would want to have multiple, you would probably use popup=manual, so that you could decide which one to close 18:20:43 I really liked the example of the popup over the fullscreen. And now I really like the elegance of the current stack implementation. 18:20:53 masonf: you can have a stack of popups, nested… in that case, the Escape-pressing would be managed for you in the right order 18:20:59 q? 18:21:12 tantek: I appreciate the thought has gone into this 18:21:19 scotto: yes +1 thanks masonf for all of this 18:21:25 sarahhigley_: +1 18:22:35 sarahhigley_: I'm leaning towards what scotto says… I wonder if there is another way to address the accessibility issue without removing blur as light dismiss. Another aspect of popup accessibility is…the desire to get rid of all of them, a quick way to 'get me out of here' 18:22:55 q? 18:22:59 q+ 18:23:03 sarahhigley_: I don't have a strong preference… I see the use case for removing blur as trigger for light dismiss, but I wonder if there are other ways to solve the problem 18:23:08 ack sarahhigley_ 18:23:31 masonf: for me, 'get me out of here' is always Escape 18:23:55 masonf: so Escape will always escape popups… if there are abusive popups, it would be easy to make a focus trap so users can never leave… 18:24:38 masonf: after I implemented this change I found it frustrating myself… it is easy to tab through a selectmenu and accidentally closing it 18:24:58 masonf: so is it most user's expectations that Tab is the way to get out of, like, a selectmenu, or Escape? 18:25:37 sarahhigley_: probably Escape. When talking abusive popups, I meant well meaning abusive popups 18:26:31 Forgive me for repetition and maybe missing a thing, but could using `focusout` instead of `blur()` resolve this? 18:26:51 sarahhigley_: I think not having TAB to get out would create an accessibility problem… if you expected it to go away on Tab, and if you're in a situation where, like, you're in a modal and don't want to hit Escape, because you're afraid that might close the modal that has your form… in any case I don't have a very strong preference 18:27:01 q? 18:27:10 masonf: I can see that fear… with popup inside of a modal… so Escape would first close the popup than the modal 18:27:17 masonf: if you press Escape twice 18:27:25 q? 18:27:26 q? 18:27:33 present+ 18:27:51 present+ 18:28:30 scotto: if we remove this… which I don't feel very strong about… would this be something people can easily add back in? like, selectmenu, maybe you would expect people to be able to tab back in… how easy would it be for authors to add it back in? 18:28:30 present+ scottkellum 18:28:40 present+ sarahhigley_ 18:28:47 present+ 18:29:03 scotto: let's say a website with a meganav… let's say the navigation is underneath the popup… now when you press escape it gets lost 18:29:28 scottkellum: that's an instance where we can't necessarily know if it is the behavior you want… so how can we make sure this is a behavior that can easily be added in 18:29:37 s/scottkellum/scotto 18:29:38 ack scotto 18:29:43 present+ BrianKardell 18:30:29 scotto: we have the case where people would add the accessible name for a link in a tooltip because the link's name itself is cut off… in which case you get a link that is announced with the name twice and that could get bad especially with long names 18:31:23 scotto: that kind of thing could be solved by a popup that can show the overflow, so that the same accessible name could be used… in which case I wouldn't want any role to be exposed for the popup because it is just the name… in that case… how would I make sure that doesn't dismiss? 18:31:38 masonf: interesting example… actually I have been mostly thinking about popup=auto in this issue 18:32:06 masonf: to your first question, it would be easy to add back light dismiss on blur for developers, it would be exactly in the same way as creating a focus trap 18:32:09 q? 18:32:22 bkardell_ has joined #openui 18:32:28 present+ 18:32:32 JonathanNeal: can focusout mitigate this? 18:32:55 masonf: yes… 18:33:24 masonf: that mitigates the accessibility issue for using defaultopen when you can't get there… but I don't think it fixes the confusion about accidental closures 18:33:38 Proposed resolution: blur() is *not* a light dismiss trigger for pop-up. 18:33:41 JonathanNeal: would you like to discuss this in the issue more or do you have a proposed resolution? 18:34:36 masonf: that would be my resolution but I am biased 18:34:52 JonathanNeal: what about saying something like we say blur is not a light dismiss trigger, but something else is ? 18:35:18 masonf: we could hold off on this today and get back to it later 18:35:38 Topic: [Popup] What is the interaction between popup and other top layer elements #520 18:35:38 github: https://github.com/openui/open-ui/issues/520 18:36:21 masonf: we discussed this one a few times…what happens when you have a combination of things in the top layer, like a modal layer with a popup attribute, or something full screen 18:36:27 q+ 18:37:32 masonf: Last time the tone of the conversation was pretty much that we want to solve these things… there were several issues here resolved. The main question that is left is @@@ 18:37:53 q+ 18:38:19 q+ 18:38:22 masonf: option one: if you call showpopup it becomes a popup and calling showmodal after would throw an error, and the other way around. Option two would be that there is some kind of order in which one takes precedence 18:39:17 masonf: there are some edge cases, like when you open using a declarative button and through JS at the same time 18:39:53 scotto: I thought it was resolved that modal dialogs cannot be a popup? 18:40:18 masonf: if you do dialog.showModal() it becomes a modal… if you then run dialog.showPopup, you shouldn't be able to then convert it ? 18:40:24 ack scotto 18:40:41 masonf: dialog.show() is not a modal, just a dialog that shows, dialog.showModal() is 18:41:02 scotto: I think there's a case for dialogs that are not modal but do want to be light dismissable 18:41:27 scotto: to your question… I think modal always wins, because that's pretty heavy semantics 18:42:03 masonf: so your vote is if you call dialog.showPopup() you have a popup, if you then call dialog.showModal(), it closes and reopens modally? 18:42:12 scotto: yes that's quite a strong indication semantically I would say 18:42:38 scotto: if modal is called that should be respected, if not, could be problematic 18:42:58 masonf: I do consider it a site bug though if you do both, seems to me like as an author you're undecided there 18:43:04 tantek has changed the topic to: https://github.com/openui/open-ui/blob/main/meetings/telecon/2022-10-06.md 18:43:17 scotto: I can see that… probably want to throw a console warning too for that 18:43:40 q? 18:43:40 scotto: but right now I feel if something is declared as modal that is something to respect… thinking about use cases but not sure 18:44:00 ack bkardell_ 18:44:42 bkardell_: if I understand what you're saying… if you have some thing that can trigger manually…if you call showPopup, it shows in the top layer as a popup. If you then call hidePopup and then showDialog that is fine? 18:44:44 masonf: yes 18:45:18 bkardell_: the second is when user clicks a button that has popuptoggletarget, would that put the popup in the top layer? 18:45:21 masonf: yes 18:45:52 bkardell_: I know we've been saying there are blurry lines between when something is a dialog vs a popup… it feels weird? 18:46:12 bkardell_: so you could have a dialog element that you can make a popup? 18:46:44 masonf: there are two things: semantically you're saying it is a dialog. You want a list of options to be presented to the users. Then there's behavior: how is it presented (on top of all other things, or not) 18:47:34 masonf: the reason people would make something a dialog, they would have something that is like a dialog… but a modalless dialog today isn't great today, because things like clicking outside of it don't work with it… with popup attr they could add such behaviors if they want it 18:48:00 bkardell_: then what is a modalless dialog and why is it not in the top layer? feels like most people would want it to be in the top layer and have most of those behaviors? 18:48:57 masonf: in my view… we probably could deprecate the modalless dialog, because it is pretty useless. And you can't animate it, and there's other behaviors you can't do with it. But that's all separate from the fact that what you put in there, it is a dialog 18:49:11 ack scottkellum 18:49:28 scottkellum: are we talking about the interplay between modals and popups? or if multiple popups are called is it also an issue to resolve what takes precedence? 18:50:04 masonf: just the first things. Multiple popups are handled by the spec pretty well. It is just the interplay between dialog and fullscreen elements on the one hand, and popup behavior on the other 18:50:07 q? 18:50:15 Proposed resolution: and
.requestFullscreen() are supported. If one API is "in use" (e.g. dialog.showModal()), a call to the other API (e.g. dialog.showPopUp()) will throw an exception. Declarative invocations will issue a console warning, and will not do anything. 18:51:01 q+ 18:51:20 masonf: so in this resolution I've put the 'option one' (first come, first served) 18:52:03 JonathanNeal: isn't there a certain one that people would want to win? 18:52:28 q? 18:52:48 scotto: if for implementation reasons, first come first served is easier, I can understand it as well. But I have slight preference for option two, giving precedence to one, and make that showModal, because showModal is a strong indication 18:52:58 scotto: but yeah, we could also throw an error in the console 18:54:16 bkardell_: this had me thinking about that dialogs have this `open` attribute… could you end up with a situation where you have two declarative forms that disagree? like the dialog is open in markup, and you have the toggle, should that throw? it looks like in the spec they throw an invalid state when you throw open on a dialog that is already shown 18:54:19 q? 18:54:22 ack bkardell_ 18:54:24 bkardell_: is the proposal to just do that? 18:54:37 tantek: it was so great to have these discussions with you again. 18:54:43 thank you for joining! 18:54:44 bkardell_: there is this concept of openness, and when it is already open, sorry, it is already open 18:54:54 masonf: yes that would be my proposal, like first come first served 18:55:02 that sounds good to me then 18:55:03 +1 18:55:13 q? 18:55:38 JonathanNeal: any concerns on the proposal? 18:55:45 bkardell_: I like it 18:56:16 +1 18:56:18 +1 to proposed (not strongly; but seems like an author problem) 18:56:41 bkardell_: what if you have open and defaultopen at the same time… like you want them to toggle but it is also open by default? 18:56:59 masonf: it can't throw, that would be a parser behavior… would have to decide, haven't thought about that 18:57:00 I would also back +1. A bit foggy on the nitty gritty, but it feels generally helpful. 18:57:05 +1 from me 18:57:11 q? 18:57:58 JonathanNeal: any objections? I'm seeing more of a consensus now 18:58:13 RESOLVED: and
.requestFullscreen() are supported. If one API is "in use" (e.g. dialog.showModal()), a call to the other API (e.g. dialog.showPopUp()) will throw an exception. Declarative invocations will issue a console warning, and will not do anything. 18:58:24 to be clear I think there are two questions masonf - I wasn't thinking of the one you said exactly 18:59:02 I was thinking you had a popuptoggletarget='foo' and a `` 18:59:10 Zakim, end meeting 18:59:10 As of this point the attendees have been masonf, JonathanNeal, hdv, dandclark, tbondwilkinson, chrishtr, dbaron, scotto, tantek, scottkellum, sarahhigley_, BrianKardell, bkardell_ 18:59:13 RRSAgent, please draft minutes 18:59:13 I have made the request to generate https://www.w3.org/2022/10/06-openui-minutes.html Zakim 18:59:15 I am happy to have been of service, hdv; please remember to excuse RRSAgent. Goodbye 18:59:19 Zakim has left #openui 18:59:38 bkardell: I realized one thing about - that's just visible, but not in the top layer. So I think it's actually 18:59:48 ok to do 19:00:00 eek 19:00:09 That would be made top-layer as a pop-up. It still wears 'open' so it's an "open dialog" but that's ok too. 19:00:19 And yeah eek is right. 19:00:21 cool but also eek 19:00:48 Thanks for the convo today 19:01:11 `` 19:01:33 :-p 19:02:13 in any case, that's a lot of characters but at least it is a nice decalative way to achive the thing some people will want without js 19:02:30 so maybe that's actually a iwn 19:02:37 win, even 19:02:50 this has been extremely interesting 19:03:56 I wrote a loong blog post draft last week on what the difference is between dialogs, modals and popups, and learned a few things today :-) thanks all 20:13:22 masonf has joined #openui 20:13:28 topic 20:13:30 topic: foo