Meeting minutes
<JonathanNeal> do we have someone to scribe while hdv is sharing? if not, I will try.
<dandclark> 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
<dandclark> hdv: So we might not need to do anything, mason does this apply to selectmenu?
<JonathanNeal> thanks, dandclark !
<dandclark> masonf: I think it does apply. Don't think we would want to do anythign different for selectmenu
masonf: would say out of the box we should support this for <selectmenu> too
masonf: prototype witse we would be fine to just support i
<dandclark> Proposed resolution: `<selectmenu>` supports `:open` as specified in the CSSWG.
<masonf> +1
+1 🎉
RESOLUTION: `<selectmenu>` supports `:open` as specified in the CSSWG.
[Popup] Should blur() be a light dismiss trigger? #415
github: https://
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
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
masonf: one way to solve it could be that Shift+TAB takes you back to the selectmenu that is then magically open
masonf: another way this could be annoying would be if the defaultopen attribute, was used
masonf: so I wonder if our previous resolution was wrong… it may be better if blur is not a light dismiss trigger
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
JonathanNeal: is this a proposal also applicable _after_ the popup has received focus?
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 universal
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
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
scotto: if you would just add `popup` attribute to a div, without adding a role, you haven't really done something accessible just yet
masonf: there is still a big difference between auto and manual… for keyboard users Escape will close auto popup but not a manual popup
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
<tantek> scotto is making one of the points I was going to bring up
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
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
<Zakim> 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 popup that's not focused?
tantek: +1 to scotto's point on existing expectations on how tab behaves in these kinds of situations
tantek: the question is, do you need to refocus the popup to escape from it?
tantek: re disclosure triangles, I thought you could have multiple of them, so would escape close multiple or not?
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?
tantek: I'm not sure if full screen is a popup?
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
masonf: it is implemented as a stack, roughly speaking
masonf: if you would want to have multiple, you would probably use popup=manual, so that you could decide which one to close
<JonathanNeal> I really liked the example of the popup over the fullscreen. And now I really like the elegance of the current stack implementation.
masonf: you can have a stack of popups, nested… in that case, the Escape-pressing would be managed for you in the right order
tantek: I appreciate the thought has gone into this
scotto: yes +1 thanks masonf for all of this
sarahhigley_: +1
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'
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
masonf: for me, 'get me out of here' is always Escape
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…
masonf: after I implemented this change I found it frustrating myself… it is easy to tab through a selectmenu and accidentally closing it
masonf: so is it most user's expectations that Tab is the way to get out of, like, a selectmenu, or Escape?
sarahhigley_: probably Escape. When talking abusive popups, I meant well meaning abusive popups
<JonathanNeal> Forgive me for repetition and maybe missing a thing, but could using `focusout` instead of `blur()` resolve this?
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
masonf: I can see that fear… with popup inside of a modal… so Escape would first close the popup than the modal
masonf: if you press Escape twice
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?
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
scotto: 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
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
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?
masonf: interesting example… actually I have been mostly thinking about popup=auto in this issue
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
JonathanNeal: can focusout mitigate this?
masonf: yes…
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
<masonf> Proposed resolution: blur() is *not* a light dismiss trigger for pop-up.
JonathanNeal: would you like to discuss this in the issue more or do you have a proposed resolution?
masonf: that would be my resolution but I am biased
JonathanNeal: what about saying something like we say blur is not a light dismiss trigger, but something else is ?
masonf: we could hold off on this today and get back to it later
[Popup] What is the interaction between popup and other top layer elements #520
github: https://
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
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 @@@
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
masonf: there are some edge cases, like when you open using a declarative button and through JS at the same time
scotto: I thought it was resolved that modal dialogs cannot be a popup?
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 ?
masonf: dialog.show() is not a modal, just a dialog that shows, dialog.showModal() is
scotto: I think there's a case for dialogs that are not modal but do want to be light dismissable
scotto: to your question… I think modal always wins, because that's pretty heavy semantics
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?
scotto: yes that's quite a strong indication semantically I would say
scotto: if modal is called that should be respected, if not, could be problematic
masonf: I do consider it a site bug though if you do both, seems to me like as an author you're undecided there
scotto: I can see that… probably want to throw a console warning too for that
scotto: but right now I feel if something is declared as modal that is something to respect… thinking about use cases but not sure
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?
masonf: yes
bkardell_: the second is when user clicks a button that has popuptoggletarget, would that put the popup in the top layer?
masonf: yes
bkardell_: I know we've been saying there are blurry lines between when something is a dialog vs a popup… it feels weird?
bkardell_: so you could have a dialog element that you can make a popup?
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)
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
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?
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
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?
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
<masonf> Proposed resolution: <dialog popup> and <div popup>.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.
masonf: so in this resolution I've put the 'option one' (first come, first served)
JonathanNeal: isn't there a certain one that people would want to win?
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
scotto: but yeah, we could also throw an error in the console
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
bkardell_: is the proposal to just do that?
<JonathanNeal> tantek: it was so great to have these discussions with you again.
<JonathanNeal> thank you for joining!
bkardell_: there is this concept of openness, and when it is already open, sorry, it is already open
masonf: yes that would be my proposal, like first come first served
<bkardell_> that sounds good to me then
<bkardell_> +1
JonathanNeal: any concerns on the proposal?
bkardell_: I like it
<sarahhigley_> +1
+1 to proposed (not strongly; but seems like an author problem)
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?
masonf: it can't throw, that would be a parser behavior… would have to decide, haven't thought about that
<JonathanNeal> I would also back +1. A bit foggy on the nitty gritty, but it feels generally helpful.
<JonathanNeal> +1 from me
JonathanNeal: any objections? I'm seeing more of a consensus now
RESOLUTION: <dialog popup> and <div popup>.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.
<bkardell_> to be clear I think there are two questions masonf - I wasn't thinking of the one you said exactly
<bkardell_> I was thinking you had a popuptoggletarget='foo' and a `<dialog id="foo" open>`