Meeting minutes
[selectmenu] Should the text inside <option>s be selectable?
<gregwhitworth> *wave*
<gregwhitworth> github: openui/
masonf: this ones pretty straightforward in terms of description, should the text be selectable when the listbox pops up should you be able to select these things
masonf: its not specced like this, but its hard to select some things and in select you cant select any of the text
masonf: im ok with anything just want to do the right thing for the user
gregwhitworth: there is no looking at the different web properties any consistency i can find in terms of comboboxes and select
gregwhitworth: lets just pick a default that makes sense, i literally dont care
gregwhitworth: we should probably use something that can be overridden by the css property, people should be able to make their stuff selectable or not selectable
dandclark: lacking a strong reason to go one way or the other, lets go with whats in the existing implementations
dandclark: native select and other datetime control popups the text is not selectable
dandclark: i was seeing the text not being selectable in bootstrap etc
dandclark: i do get a caret when hovering over things in listbox which seems weird, preference to make it not selectable
dandclark: authors should still be able to override (not a !important rule)
<JakeA> _speaking_
jakea: so you want to be able to put richer content in selectmenu, so it might be worth thinking about whether links should be clickable
jakea: you could imagine a select and one of the items has a trash can to delete items or add items
jakea: if use no user-select, does that impact that as well?
masonf: its a button though, you could still click it you just cant highlight the text
jakea: that clarifies it, i didnt know if this was just about select
jakea: if we are going with consistency with select, theres a difference there. select just has one thing per option
jakea: if we are adding richer content, then maybe consistency with select is not the goal
masonf: a selectmenu is primarily still just for picking options
masonf: if there is something else to do with options that is an accessibility gray area
brecht: agree that defaults with select
brecht: if it doesnt have any accessibility issues to make it selectable then i dont see any reason we shouldnt be able to override it with css
brecht: could add value to this new ui
scotto: i agree with not making the options inherently selectable
scotto: the rich content throws a wrench into this
scotto: the only thing that comes to mind for an accessibility thing is more for if they have a motor disability where they are trying to select an option but one could accidentally click and drag and select a piece of the text, how is that supposed to behave
scotto: how do we know if someone is trying to select an option or they have a tremor and now theyve selected the text
scotto: does that mean they need to click again
scotto: buttons dont behave this way for similar reasons
scotto: if its overridable thats probably enough but it shouldnt be the default
<dandclark> That's a great point
jhey: mason hit what i was going to say
jhey: if you want to add buttons to things youd probably just create another control. a button that just anchors a popover to it
gregwhitworth: jake the scenario you brought up has been brought up before, like a composited control
<masonf> Proposed resolution: options in a selectmenu are user-select:none, but not !important, via the UA stylesheet.
<dandclark> +1
RESOLUTION: options in a selectmenu are user-select:none, but not !important, via the UA stylesheet.
gregwhitworth: what this means is that authors can override user-select:none
[popover] Timing of <dialog> 'close' event, popover 'toggle' event, <details> 'toggle' even
<gregwhitworth> github: whatwg/
jakea: so we've got with both popover and with dialog, you get an event at the end of stuff has happened, so close and toggle events on dialog and popovers respectively
jakea: but the way theyve been specced is that a task is queued to fire that event
jakea: but these events are already happening on the main thread, in response to a click or a javascript call, its already on the main thread
jakea: so queueing a task that means that the event is going to sit on either side of the next render, it might happen before or after, and that seems bad for an event thats like hi im here now
jakea: the things the developer does might happen a frame late
jakea: i propose we ensure the event fires before the next render, a couple of ways of doing that
jakea: we could dispatch the event synchronously, which matches the rest of the platform, but because some of this is related to dom changes, apparently we dont like to fire events in response to dom changes
jakea: we could dispatch it in a microtask, which also feels like the compatible thing to do since going from async to sync could break stuff
jakea: a microtask will always be before the next render
masonf: i kind of like the model that there is a beforetoggle that is synchronous, its before anything happens and you can cancel it
masonf: and we have toggle, which maybe should have been called aftertoggle
masonf: i wonder if we could add beforetoggle to details and beforeclose to dialog
jakea: thats possible but thats a separate thing. so we have the event thats cancelable and then we have the event thats im here now
jakea: adding a before event which isnt a predictable im here now event, these seems like separate things
masonf: i am supportive of switching to microtask
flackr: i agree that this should be an event that developers if they do something in that event is guaranteed to happen before the next render
<gregwhitworth> +1 to microtask
flackr: are we guaranteed that there is a microtask checkpoint?
jakea: we are guaranteed, the only time we arent guaranteed of a microtask checkpoint is if youre already in the render steps
jakea: the only way a popover can be shown in that case is when a popover is shown from script inside rendering
masonf: it can be dispatched through a click on a button which has no script
jakea: a click is going to be a task, and there is a microtask checkpoint after tasks regardless of stack
jakea: its worth asking, i went and checked
<JakeA> Proposed resolution: Fire "closed" and "toggle" events in a microtask rather than a task
<masonf> +1
<dandclark> +1
<flackr> +1
RESOLUTION: Fire "closed" and "toggle" events in a microtask rather than a task
Should popover/dialog show/hide when already shown/hidden throw?
jakea: if you call close on a closed dialog, or you call show on an open dialog, it doesnt throw
jakea: unless the dialog is also an open popover
<dbaron> (this is https://
jakea: if you call showmodal on an open dialog or show on an open dialog thats also in the popover showing state
jakea: we've got inconsistency, ive been trying to think that we should do
jakea: looking at most of the web platform, we tend to just noop if the request is to do something that will leave it in the same state
jakea: if you remove something from a set that nots there, remove an element thats not in a document, remove an event listener that doesnt exist, it just noops
jakea: there are a couple examples that are different, element.removechild if you give it an element thats not there it will throw
jakea: these tend to be older ancient apis
jakea: exitfullscreen if you call it while not in fullscreen it will throw, whereas requestfullscreen on something thats already fullscreen is fine
jakea: its all over the place
jakea: thinking about how people tend to think of things on the web, all the frameworks are built around an idea that you build a state and if everything is already in that state then its fine
jakea: im leaning that we should do that model here
jakea: there are a couple options for that
jakea: specifically for popover, if you say showpopover and the popovers already shown we could do nothing or make sure that popovers at the top
jakea: i dont have a feeling what to do there
jakea: for dialog we have two kinds of showing, we could noop or we could switch from one to the other
jakea: modal to non-modal
jakea: or maybe that is a case where throwing is fine, we just document it as an edge case
jakea: and then weve got the issues around if you try to show a dialog as a popover, what to do there
jakea: maybe again if these features are incompatbiel then throwing is an option as an edge case
jakea: or we try to make sure these features cant be used at the same time
jakea: what do folks thing
masonf: my opinions in reverse order
masonf: we did discuss the dialog popover case
masonf: we should not allow that at all, but there are use cases and there are accessibility cases
<gregwhitworth> I'm going to need to drop but I'm supportive of noop unless there is an area where it's not possible?? I can't think of one at the moment
masonf: so we cant outlaw that entirely
masonf: if you show with dialog and popover, youve done something wrong and we should let you know with an exception
masonf: if you call showpopover twice on a popover i have no problem not throwing, same thing for hide, we randomly decided to throw an exception and its fine not to
masonf: on the dialog case and dialog popover case, i think we should throw exceptions when you try to switch modes modal non-modal
masonf: if we dont throw exceptions then we need to at least close and then reopen, we shouldnt do a magical upgrade between modal and non-modal
masonf: theres all kinds of algorithms that will mess up
jakea: one fun edge case there is with the events we just spoke about, with the microtasks if we hide and show
jakea: make sure that these are all happening in the right order
masonf: thats exactly what im worried about
jhey: same thing as mason, i built a lot of popover demos and being able to pop to the top of the stack again would be super useful
jhey: three or four lines of boilerplate every time you want to move something to the top
jhey: massive dx win
jakea: so no toggle event needed?
jhey: if its already showing, then you already have something thats been triggered when it was first shown
jhey: if youre going to do something again when it goes up you could just do it at that point
jhey: its pretty edge casey, not many demos need it
masonf: theres a nuance there if you say the same thing about popovers
masonf: promoting something to the top is complicated because youre reordering things
jhey: yeah i was talking about popover
jhey: the moment you have to check if its already open and then hide it and show it to bring it to the top is unintuitive
jhey: hopefully we dont need another method to move it to the top
jakea: we should not pass that complexity on to every developer
masonf: if we want to support that we need to think about the consequences
masonf: if you have 3 nested popovers, they are ancestors of each other
masonf: if you promote the first to the top you need to close the other two
masonf: theres a chain of things that will happen, including other popovers that will close
masonf: it might be a footgun, you might never get the thing that you want
masonf: you can never put one on top of two and three if one of an ancestor
jhey: i think id rather have that edge case than every time i want to promote something i have to do a workaround
masonf: the way popover ancestors are defined you can never do that
masonf: so youre talking manual popovers
jhey: yes
masonf: ok yeah thats fair
jakea: lets try to break this up
<JakeA> Proposed resolution: Popover should not throw on show/hide when in that state. More discussion needed around "pop to top behaviour"
jakea: for those examples, i dont have the examples in my head so it would be good to write up more of the problem
RESOLUTION: Popover should not throw on show/hide when in that state. More discussion needed around "pop to top behaviour"
jakea: for popover dialog - dont cross the streams?
masonf: yes
<JakeA> Proposed resolution: Still throw when trying to switch from open popover to open dialog
scotto: i would be very concerned if someone can do showPopover and then do showModal
jakea: i think its fine to noop if youre an open popover and then you try to close dialog
masonf: and vice versa?
jakea: agreed
<JakeA> Proposed resolution: Still throw when trying to switch from open popover to open dialog. Although it's fine to hide a popover that's already hidden, but it's a shown dialog (and vice versa)
masonf: so you get an exception when youre trying to change modes
RESOLUTION: Still throw when trying to switch from open popover to open dialog. Although it's fine to hide a popover that's already hidden, but it's a shown dialog (and vice versa)
<JakeA> Proposed resolution: For dialog, throw when trying to switch shown modes, but don't throw if call is for the current state (eg hidden to hidden)
jakea: if youre trying to go from showmodal to show, or vice versa, it throws
masonf: does it currently throw both ways?
masonf: we can resolve that the behavior stays the same as it is now but it would be good to clarify
jakea: normal show on a open dialog does not throw. that seems bad though, right?
jakea: if you do the call like i want you to be non-modal and it just noops that seems weird
masonf: it feels similar to the popover dialog case, its a mistake that you should be notified with an exception
masonf: on this one there are potential web compat issues
jakea: that might fall by the wayside then
masonf: lets resolve what we think the right behavior is, subject to web compat testing
<JakeA> Proposed resolution: For dialog, throw when trying to switch shown modes, but don't throw if call is for the current state (eg hidden to hidden). Subject to webcompat testing
RESOLUTION: For dialog, throw when trying to switch shown modes, but don't throw if call is for the current state (eg hidden to hidden). Subject to webcompat testing
Should togglePopover() return a boolean? #9043
<masonf> github: whatwg/
jakea: weve got togglepopover
jakea: i believe that was added for consistency in the platform where we have toggles like domtokenlist
jakea: but, in those other toggle places it returns a boolean so you know which way it went
jakea: for compatibility, should we return a boolean?
dbaron: im hoping the boolean returns the new state
jakea: whatever classlist does, which i believe it is yes
masonf: yes
<flackr> +1
<Brecht_DR> sounds good, consistent
<JakeA> Proposed resolution: `togglePopover` should return a boolean representing the new state
RESOLUTION: `togglePopover` should indeed return a boolean representing the new state
<dbaron> https://
Is it ok for popover to claim general names like :open and :closed? #9055
<masonf> github: whatwg/
<JakeA> whatwg/
jakea: according to html spec, :open and :closed only apply to popovers and nothing else
jakea: but it seems like there is some appetite for other things like details and select and dialog
jakea: and theres a resolution that suggests that
jakea: there is some risk in doing that later since developers get into their head that this is a popover feature, they write code that assumes its only for popovers
jakea: then if we change it that will blow up
jakea: even if that change can be made im worried about the differnet definitions of open
jakea: its normal for psueco classes to be vague and have many definitions like :default
jakea: which applies to the default selected radio button
jakea: but with buttons its the default button for submitting a form
jakea: but in those cases you can use selectors to limit which definition of default youre talking about
jakea: but if you have dialog:open that can mean open dialog or open popver
jakea: maybe too similar maybe not idk
jakea: details:open select:open can mean pretty different things
jakea: it can be two kinds of open at the same time
jakea: with :closed pseudo class its an element with open and closed states and its currently closes
jakea: you can have a details popover where both classes apply at the same time
jakea: we can change that in the spec
jakea: instead of an element with open and closed state, but then weve shifted the problem around a bit
jakea: what does details open mean? it could mean the details is used as a popover, but still closed as a details element
jakea: sounds messy, what should we do
masonf: for context, there was a several meeting long discussion in csswg to get here
masonf: there was a general desire to make these general
masonf: css is defined generally, anything that has an open state
masonf: details popover is troublesome
masonf: two aspects: csswg resolution said it should be general, whats missing is that in whatwg/html we should define it
<dbaron> (This also feels like it goes back to the discussion about popover being an attribute or an element.)
masonf: but i think your point brings up a problem that we should bring back to csswg
masonf: because things can be open or closed in multiple ways
masonf: they could be called popoveropen and detailsopen
masonf: i hesitate to reopen can of worms
scotto: yeah being more specific makes sense
scotto: i dont disagree with jakes problem that he brought up
scotto: who is doing to make a details popover
scotto: yeah thats a problem, but also they shouldnt be doing that
scotto: i guess im just kind of wondering should the open pseudo selector
scotto: should the select element, what is the use case for that? obviously select is difficult to style
scotto: would that apply in the combobox state? what about when size>1 and its always open
scotto: these pseudo selectors dont make sense on certain elements
scotto: details is just weird
scotto: i dont know how to solve that without really looking at details summary and taking a modern perspective and that we should fix this because it has other issues
scotto: yes agree solve the problem, but dont know how to fix it without burning everything down
jakea: yeah we dont want to put footguns into the platform
jakea: if we dont think that people should make details popovers we can enforce that
jakea: we are going to have to think about other things in the future that are openable tlike selectmenu
jakea: openables which are created by an attribute rather than a new element, difficult to make rules about that
jakea: if theres another one in the future, its difficult to pull those apart
dbaron: some of this ambiguity is related to popover being an attribute rather than en element
dbaron: that was a long discussion
dbaron: maybe the issue with the pseudo classes is that :open and :closed should be open and closed that is associated with the type of element
dbaron: maybe there should be a separate pseudo class for popover since it can intersect with the others
dbaron: a details open closed cant intersect with a summary open and closed
masonf: fullscreen was debatably on the border of something open and closed, another thing where any element can be open or closed
dbaron: maybe fullscreen should be another, shouldnt use open and closed
masonf: it already has :fullscreen so maybe it doesnt need :open
<tantek> does that imply that popover should have its own pseudo?
<dbaron> yes, that's what I was suggesting
<tantek> :popped
masonf: modulo select, details and dialog cases can be disambiguated with attribute selector
jakea: we can remove the overlap by saying that popover does not work on anything that is otherwise openable
jakea: or we come up with more specific names for different kinds of open
masonf: the only one i want an exception for is dialog
masonf: and im a little fearful
masonf: how we got here with an attribute is that the semantics of the things that are popping up are based on the element
<Brecht_DR> (Mason said it... agree with the dialog)
masonf: if you want the semantics of a details then you should be able to do that
scotto: to be fair details doesnt have a role
jakea: should we take this to the csswg then?
masonf: it would be good since we have a lot of good context here,is there anything we agree on?
masonf: david said that fullscreen can apply to any element and therefore it has its own pseuco class
<dbaron> (I also wonder how to tell the semantic difference between a details that's *inside* a popover and a details that *is* a popover.)
masonf: maybe popover should have its own pseudo class
masonf: in addition to supporting open
masonf: popover has an additional one to disambiguate
jakea: whats the use case?
masonf: animations is one of the
jhey: you can use something like has, has this popover opened somewhere in the page, stuff like that
jhey: general transition stuff
jhey: those are the kind of use cases, tell if something is open
jakea: good point, its useful
flackr: you need the state change to transition the trigger away
flackr: is there a need for a pseudo class for a popover thats not open? like just one pseudo class for popover in the open state
<Zakim> tantek, you wanted to support separate pseudo
masonf: thats parallel to fullscreen i like it
tantek: +1 to support separate pseudo class
tantek: take it to csswg when there is a specific proposal, that way there is less time spent bikeshedding
tantek: lets bikeshed here
tantek: there is only :fullscreen, you can use :not to check that its not in fullscreen, good place to start
<JakeA> Proposed resolution: Talk to CSSWG about specific pseudo-class instead of `:open`, such as `:popover` (similar to `:fullscreen`)
<masonf> Proposed resolution: add a :popover pseudo class that applies only to open popovers.
tantek: maybe this is a way of saying that open and closed should be something else completely
<tantek> +1
masonf: maybe :open and :closed is not needed at all
jakea: maybe :open is handy for details and select, selectmenu in particular
jakea: if popover is a different thing then we've removed the overlap so its fine
RESOLUTION: Talk to CSSWG about specific pseudo-class instead of `:open`, such as `:popover` (similar to `:fullscreen`)
<Brecht_DR> +1
<dbaron> yes, that works, there's an icon in the upper right corner now
<dbaron> (they split 30 minutes each)