14:50:39 <RRSAgent> RRSAgent has joined #openui
14:50:43 <RRSAgent> logging to https://www.w3.org/2023/03/23-openui-irc
14:55:37 <gregwhitworth> Zakim, start meeting
14:55:37 <Zakim> RRSAgent, make logs Public
14:55:39 <Zakim> please title this meeting ("meeting: ..."), gregwhitworth
14:55:47 <gregwhitworth> meeting: Open UI Telecon
15:00:52 <Brecht_DR> Brecht_DR has joined #openui
15:01:58 <flackr> flackr has joined #openui
15:02:18 <jhey> jhey has joined #openui
15:02:20 <jarhar> jarhar has joined #openui
15:02:49 <masonf> masonf has joined #openui
15:03:27 <dandclark> present+
15:03:52 <scotto> scotto has joined #openui
15:03:58 <flackr> present+
15:03:59 <Brecht_DR> present+
15:04:02 <JakeA> present+
15:04:09 <gregwhitworth> Topic: [selectmenu] Should the text inside <option>s be selectable?
15:04:28 <dbaron> Present+
15:04:40 <gregwhitworth> *wave*
15:05:00 <dbaron> ScribeNick: jarhar
15:05:09 <gregwhitworth> github: https://github.com/openui/open-ui/issues/687
15:05:17 <kizu> kizu has joined #openui
15:05:38 <jarhar> 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
15:05:40 <gregwhitworth> q+
15:05:42 <dandclark> q+
15:05:55 <jarhar> masonf: its not specced like this, but its hard to select some things and in select you cant select any of the text
15:06:04 <jarhar> masonf: im ok with anything just want to do the right thing for the user
15:06:26 <jarhar> gregwhitworth: there is no looking at the different web properties any consistency i can find in terms of comboboxes and select
15:06:38 <jarhar> gregwhitworth: lets just pick a default that makes sense, i literally dont care
15:06:50 <JakeA> q+
15:06:56 <gregwhitworth> ack gregwhitworth
15:06:56 <jarhar> 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
15:07:07 <gregwhitworth> ack dandclark
15:07:11 <jarhar> dandclark: lacking a strong reason to go one way or the other, lets go with whats in the existing implementations
15:07:28 <jarhar> dandclark: native select and other datetime control popups the text is not selectable
15:07:38 <jarhar> dandclark: i was seeing the text not being selectable in bootstrap etc
15:07:56 <Brecht_DR> q+
15:08:01 <scotto> q+
15:08:01 <jarhar> dandclark: i do get a carrot when hovering over things in listbox which seems weird, preference to make it not selectable
15:08:17 <jarhar> dandclark: authors should still be able to override
15:08:17 <JakeA> _speaking_
15:08:21 <gregwhitworth> ack JakeA
15:08:37 <dbaron> s/still be able to override/still be able to override (not a !important rule)/
15:08:45 <dbaron> s/carrot/caret/
15:08:45 <jarhar> 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
15:09:00 <jarhar> jakea: you could imagine a select and one of the items has a trash can to delete items or add items
15:09:09 <jhey> q+
15:09:10 <jarhar> jakea: if use no user-select, does that impact that as well?
15:09:24 <jarhar> masonf: its a button though, you could still click it you just cant highlight the text
15:09:33 <jarhar> jakea: that clarifies it, i didnt know if this was just about select
15:09:45 <gregwhitworth> q+
15:09:45 <jarhar> jakea: if we are going with consistency with select, theres a difference there. select just has one thing per option
15:09:54 <jarhar> jakea: if we are adding richer content, then maybe consistency with select is not the goal
15:10:07 <jarhar> masonf: a selectmenu is primarily still just for picking options
15:10:20 <jarhar> masonf: if there is something else to do with options that is an accessibility gray area
15:10:35 <gregwhitworth> ack Brecht_DR
15:10:46 <jarhar> brecht: agree that defaults with select
15:11:05 <jarhar> 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
15:11:09 <jarhar> brecht: could add value to this new ui
15:11:11 <gregwhitworth> ack scotto
15:11:29 <jarhar> scotto: i agree with not making the options inherently selectable
15:11:29 <gregwhitworth> ack gregwhitworth
15:11:38 <jarhar> scotto: the rich content throws a wrench into this
15:12:08 <jarhar> 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
15:12:31 <jarhar> scotto: how do we know if someone is trying to select an option or they have a tremor and now theyve selected the text
15:12:37 <jarhar> scotto: does that mean they need to click again
15:12:42 <jarhar> scotto: buttons dont behave this way for similar reasons
15:12:55 <jarhar> scotto: if its overridable thats probably enough but it shouldnt be the default
15:13:03 <dandclark> That's a great point
15:13:09 <gregwhitworth> ack jhey
15:13:15 <jarhar> jhey: mason hit what i was going to say
15:13:30 <jarhar> jhey: if you want to add buttons to things youd probably just create another control. a button that just anchors a popover to it
15:13:51 <jarhar> gregwhitworth: jake the scenario you brought up has been brought up before, like a composited control
15:14:08 <masonf> Proposed resolution: options in a selectmenu are user-select:none, but not !important, via the UA stylesheet.
15:14:18 <dandclark> +1
15:14:38 <masonf> RESOLVED: options in a selectmenu are user-select:none, but not !important, via the UA stylesheet.
15:14:39 <jarhar> gregwhitworth: what this means is that authors can override user-select:none
15:15:08 <gregwhitworth> Topic: [popover] Timing of <dialog> 'close' event, popover 'toggle' event, <details> 'toggle' even
15:15:19 <gregwhitworth> github: https://github.com/whatwg/html/issues/9046
15:17:08 <jarhar> 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
15:17:15 <jarhar> jakea: but the way theyve been specced is that a task is queued to fire that event
15:17:31 <jarhar> 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
15:17:50 <masonf> q+
15:18:00 <jarhar> 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
15:18:12 <jarhar> jakea: the things the developer does might happen a frame late
15:18:22 <jarhar> jakea: i propose we ensure the event fires before the next render, a couple of ways of doing that
15:18:42 <jarhar> 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
15:18:58 <flackr> q+
15:19:06 <jarhar> 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
15:19:13 <jarhar> jakea: a microtask will always be before the next render
15:19:23 <gregwhitworth> ack masonf
15:19:49 <jarhar> masonf: i kind of like the model that there is a beforetoggle that is synchronous, its before anything happens and you can cancel it
15:19:58 <jarhar> masonf: and we have toggle, which maybe should have been called aftertoggle
15:20:10 <jarhar> masonf: i wonder if we could add beforetoggle to details and beforeclose to dialog
15:20:32 <jarhar> 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
15:20:48 <jarhar> jakea: adding a before event which isnt a predictable im here now event, these seems like separate things
15:20:55 <jarhar> masonf: i am supportive of switching to microtask
15:20:59 <gregwhitworth> ack flackr
15:21:17 <jarhar> 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
15:21:18 <gregwhitworth> +1 to microtask
15:21:26 <jarhar> flackr: are we guaranteed that there is a microtask checkpoint?
15:21:42 <jarhar> jakea: we are guaranteed, the only time we arent guaranteed of a microtask checkpoint is if youre already in the render steps
15:22:00 <jarhar> jakea: the only way a popover can be shown in that case is when a popover is shown from script inside rendering
15:22:11 <jarhar> masonf: it can be dispatched through a click on a button which has no script
15:22:23 <jarhar> jakea: a click is going to be a task, and there is a microtask checkpoint after tasks regardless of stack
15:22:31 <jarhar> jakea: its worth asking, i went and checked
15:22:35 <gregwhitworth> q?
15:23:35 <JakeA> Proposed resolution: Fire "closed" and "toggle" events in a microtask rather than a task
15:23:40 <masonf> +1
15:23:43 <dandclark> +1
15:23:49 <flackr> +1
15:24:01 <JakeA> RESOLVED: Fire "closed" and "toggle" events in a microtask rather than a task
15:24:26 <gregwhitworth> Topic: Should popover/dialog show/hide when already shown/hidden throw?
15:25:40 <jarhar> jakea: if you call close on a closed dialog, or you call show on an open dialog, it doesnt throw
15:25:52 <jarhar> jakea: unless the dialog is also an open popover
15:26:00 <dbaron> (this is https://github.com/whatwg/html/issues/9045)
15:26:07 <jarhar> jakea: if you call showmodal on an open dialog or show on an open dialog thats also in the popover showing state
15:26:21 <jarhar> jakea: we've got inconsistency, ive been trying to think that we should do
15:26:36 <jarhar> 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
15:26:53 <jarhar> 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
15:27:08 <jarhar> jakea: there are a couple examples that are different, element.removechild if you give it an element thats not there it will throw
15:27:16 <jarhar> jakea: these tend to be older ancient apis
15:27:34 <jarhar> jakea: exitfullscreen if you call it while not in fullscreen it will throw, whereas requestfullscreen on something thats already fullscreen is fine
15:27:37 <masonf> q+
15:27:39 <jarhar> jakea: its all over the place
15:28:03 <jarhar> 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
15:28:08 <gregwhitworth> q+
15:28:10 <jarhar> jakea: im leaning that we should do that model here
15:28:14 <jarhar> jakea: there are a couple options for that
15:28:30 <jarhar> 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
15:28:36 <jarhar> jakea: i dont have a feeling what to do there
15:28:51 <jarhar> jakea: for dialog we have two kinds of showing, we could noop or we could switch from one to the other
15:28:53 <gregwhitworth> ack gregwhitworth
15:28:54 <jarhar> jakea: modal to non-modal
15:28:58 <jhey> q+
15:29:05 <jarhar> jakea: or maybe that is a case where throwing is fine, we just document it as an edge case
15:29:17 <jarhar> jakea: and then weve got the issues around if you try to show a dialog as a popover, what to do there
15:29:30 <jarhar> jakea: maybe again if these features are incompatbiel then throwing is an option as an edge case
15:29:36 <jarhar> jakea: or we try to make sure these features cant be used at the same time
15:29:40 <jarhar> jakea: what do folks thing
15:30:00 <jarhar> masonf: my opinions in reverse order
15:30:06 <jarhar> masonf: we did discuss the dialog popover case
15:30:22 <jarhar> masonf: we should not allow that at all, but there are use cases and there are accessibility cases
15:30:23 <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
15:30:34 <jarhar> masonf: so we cant outlaw that entirely
15:30:48 <jarhar> masonf: if you show with dialog and popover, youve done something wrong and we should let you know with an exception
15:31:07 <jarhar> 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
15:31:22 <jarhar> masonf: on the dialog case and dialog popover case, i think we should throw exceptions when you try to switch modes modal non-modal
15:31:39 <jarhar> 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
15:31:47 <jarhar> masonf: theres all kinds of algorithms that will mess up
15:32:08 <jarhar> jakea: one fun edge case there is with the events we just spoke about, with the microtasks if we hide and show
15:32:16 <jarhar> jakea: make sure that these are all happening in the right order
15:32:19 <jarhar> masonf: thats exactly what im worried about
15:32:21 <masonf> q?
15:32:29 <masonf> ack masonf
15:32:34 <masonf> ack jhey
15:32:48 <jarhar> 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
15:33:04 <jarhar> jhey: three or four lines of boilerplate every time you want to move something to the top
15:33:10 <jarhar> jhey: massive dx win
15:33:16 <jarhar> jakea: so no toggle event needed?
15:33:27 <jarhar> jhey: if its already showing, then you already have something thats been triggered when it was first shown
15:33:36 <jarhar> jhey: if youre going to do something again when it goes up you could just do it at that point
15:33:44 <jarhar> jhey: its pretty edge casey, not many demos need it
15:33:55 <jarhar> masonf: theres a nuance there if you say the same thing about popovers
15:34:05 <jarhar> masonf: promoting something to the top is complicated because youre reordering things
15:34:09 <jarhar> jhey: yeah i was talking about popover
15:34:30 <jarhar> 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
15:34:47 <jarhar> jhey: hopefully we dont need another method to move it to the top
15:34:56 <jarhar> jakea: we should not pass that complexity on to every developer
15:35:03 <jarhar> masonf: if we want to support that we need to think about the consequences
15:35:12 <jarhar> masonf: if you have 3 nested popovers, they are ancestors of each other
15:35:21 <jarhar> masonf: if you promote the first to the top you need to close the other two
15:35:43 <jarhar> masonf: theres a chain of things that will happen, including other popovers that will close
15:35:55 <jarhar> masonf: it might be a footgun, you might never get the thing that you want
15:36:05 <jarhar> masonf: you can never put one on top of two and three if one of an ancestor
15:36:20 <jarhar> jhey: i think id rather have that edge case than every time i want to promote something i have to do a workaround
15:36:31 <jarhar> masonf: the way popover ancestors are defined you can never do that
15:36:35 <xiaochengh> xiaochengh has joined #openui
15:36:48 <jarhar> masonf: so youre talking manual popovers
15:36:50 <jarhar> jhey: yes
15:36:51 <masonf> q?
15:36:53 <jarhar> masonf: ok yeah thats fair
15:37:12 <jarhar> jakea: lets try to break this up
15:37:48 <JakeA> Proposed resolution: Popover should not throw on show/hide when in that state. More discussion needed around "pop to top behaviour"
15:38:06 <jarhar> jakea: for those examples, i dont have the examples in my head so it would be good to write up more of the problem
15:38:33 <JakeA> RESOLVED: Popover should not throw on show/hide when in that state. More discussion needed around "pop to top behaviour"
15:39:18 <jarhar> jakea: for popover dialog - dont cross the streams?
15:39:19 <jarhar> masonf: yes
15:39:31 <JakeA> Proposed resolution: Still throw when trying to switch from open popover to open dialog
15:39:32 <jarhar> scotto: i would be very concerned if someone can do showPopover and then do showModal
15:39:55 <jarhar> jakea: i think its fine to noop if youre an open popover and then you try to close dialog
15:40:03 <jarhar> masonf: and vice versa?
15:40:05 <jarhar> jakea: agreed
15:40:27 <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)
15:40:34 <jarhar> masonf: so you get an exception when youre trying to change modes
15:41:41 <JakeA> RESOLVED: 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)
15:41:47 <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)
15:42:26 <jarhar> jakea: if youre trying to go from showmodal to show, or vice versa, it throws
15:42:30 <jarhar> masonf: does it currently throw both ways?
15:42:51 <jarhar> masonf: we can resolve that the behavior stays the same as it is now but it would be good to clarify
15:43:08 <jarhar> jakea: normal show on a open dialog does not throw. that seems bad though, right?
15:43:24 <jarhar> jakea: if you do the call like i want you to be non-modal and it just noops that seems weird
15:43:36 <jarhar> masonf: it feels similar to the popover dialog case, its a mistake that you should be notified with an exception
15:43:47 <jarhar> masonf: on this one there are potential web compat issues
15:43:53 <jarhar> jakea: that might fall by the wayside then
15:44:04 <jarhar> masonf: lets resolve what we think the right behavior is, subject to web compat testing
15:44:07 <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
15:44:43 <JakeA> RESOLVED: 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
15:45:03 <masonf> topic: Should togglePopover() return a boolean? #9043
15:45:13 <masonf> github: https://github.com/whatwg/html/issues/9043
15:45:34 <jarhar> jakea: weve got togglepopover
15:45:47 <jarhar> jakea: i believe that was added for consistency in the platform where we have toggles like domtokenlist
15:45:59 <jarhar> jakea: but, in those other toggle places it returns a boolean so you know which way it went
15:46:05 <jarhar> jakea: for compatibility, should we return a boolean?
15:46:07 <masonf> q?
15:46:08 <masonf> q+
15:46:25 <jarhar> dbaron: im hoping the boolean returns the new state
15:46:32 <jarhar> jakea: whatever classlist does, which i believe it is yes
15:46:38 <jarhar> masonf: yes
15:46:45 <masonf> q?
15:46:47 <masonf> ack masonf
15:46:53 <flackr> +1
15:46:54 <Brecht_DR> sounds good, consistent
15:46:55 <JakeA> Proposed resolution: `togglePopover` should return a boolean representing the new state
15:47:13 <JakeA> RESOLVED: `togglePopover` should indeed return a boolean representing the new state
15:47:13 <dbaron> https://developer.mozilla.org/en-US/docs/Web/API/DOMTokenList/toggle
15:47:24 <masonf> topic: Is it ok for popover to claim general names like :open and :closed? #9055
15:47:32 <masonf> github: https://github.com/whatwg/html/issues/9055
15:47:39 <JakeA> https://github.com/whatwg/html/issues/9055#issuecomment-1481122980
15:47:39 <masonf> q?
15:47:52 <masonf> q+
15:47:56 <jarhar> jakea: according to html spec, :open and :closed only apply to popovers and nothing else
15:48:05 <jarhar> jakea: but it seems like there is some appetite for other things like details and select and dialog
15:48:12 <jarhar> jakea: and theres a resolution that suggests that
15:48:31 <jarhar> 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
15:48:37 <jarhar> jakea: then if we change it that will blow up
15:48:48 <jarhar> jakea: even if that change can be made im worried about the differnet definitions of open
15:48:58 <jarhar> jakea: its normal for psueco classes to be vague and have many definitions like :default
15:49:05 <jarhar> jakea: which applies to the default selected radio button
15:49:14 <jarhar> jakea: but with buttons its the default button for submitting a form
15:49:30 <jarhar> jakea: but in those cases you can use selectors to limit which definition of default youre talking about
15:49:39 <jarhar> jakea: but if you have dialog:open that can mean open dialog or open popver
15:49:43 <jarhar> jakea: maybe too similar maybe not idk
15:49:54 <jarhar> jakea: details:open select:open can mean pretty different things
15:49:59 <jarhar> jakea: it can be two kinds of open at the same time
15:50:14 <jarhar> jakea: with :closed pseudo class its an element with open and closed states and its currently closes
15:50:24 <jarhar> jakea: you can have a details popover where both classes apply at the same time
15:50:29 <jarhar> jakea: we can change that in the spec
15:50:46 <jarhar> jakea: instead of an element with open and closed state, but then weve shifted the problem around a bit
15:50:56 <scotto> q+
15:50:59 <jarhar> jakea: what does details open mean? it could mean the details is used as a popover, but still closed as a details element
15:51:05 <jarhar> jakea: sounds messy, what should we do
15:51:18 <jarhar> masonf: for context, there was a several meeting long discussion in csswg to get here
15:51:24 <jarhar> masonf: there was a general desire to make these general
15:51:34 <tantek> tantek has joined #openui
15:51:34 <jarhar> masonf: css is defined generally, anything that has an open state
15:51:39 <jarhar> masonf: details popover is troublesome
15:51:54 <jarhar> masonf: two aspects: csswg resolution said it should be general, whats missing is that in whatwg/html we should define it
15:51:56 <dbaron> (This also feels like it goes back to the discussion about popover being an attribute or an element.)
15:52:05 <jarhar> masonf: but i think your point brings up a problem that we should bring back to csswg
15:52:15 <jarhar> masonf: because things can be open or closed in multiple ways
15:52:26 <jarhar> masonf: they could be called popoveropen and detailsopen
15:52:31 <jarhar> masonf: i hesitate to reopen can of worms
15:52:40 <masonf> ack masonf
15:52:44 <masonf> ack scotto
15:52:50 <jarhar> scotto: yeah being more specific makes sense
15:53:27 <jarhar> scotto: i dont disagree with jakes problem that he brought up
15:53:27 <jarhar> scotto: who is doing to make a details popover
15:53:27 <masonf> q+
15:53:27 <jarhar> scotto: yeah thats a problem, but also they shouldnt be doing that
15:53:58 <jarhar> scotto: i guess im just kind of wondering should the open pseudo selector
15:53:58 <jarhar> scotto: should the select element, what is the use case for that? obviously select is difficult to style
15:54:09 <jarhar> scotto: would that apply in the combobox state? what about when size>1 and its always open
15:54:21 <jarhar> scotto: these pseudo selectors dont make sense on certain elements
15:54:23 <jarhar> scotto: details is just weird
15:54:40 <jarhar> 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
15:54:40 <masonf> q?
15:54:53 <jarhar> scotto: yes agree solve the problem, but dont know how to fix it without burning everything down
15:54:53 <tantek> present+
15:55:01 <jarhar> jakea: yeah we dont want to put footguns into the platform
15:55:10 <jarhar> jakea: if we dont think that people should make details popovers we can enforce that
15:55:26 <jarhar> jakea: we are going to have to think about other things in the future that are openable tlike selectmenu
15:55:38 <jarhar> jakea: openables which are created by an attribute rather than a new element, difficult to make rules about that
15:55:46 <jarhar> jakea: if theres another one in  the future, its difficult to pull those apart
15:55:57 <jarhar> dbaron: some of this ambiguity is related to popover being an attribute rather than en element
15:56:03 <jarhar> dbaron: that was a long discussion
15:56:23 <jarhar> 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
15:56:34 <jarhar> dbaron: maybe there should be a separate pseudo class for popover since it can intersect with the others
15:56:43 <jarhar> dbaron: a details open closed cant intersect with a summary open and closed
15:57:01 <jarhar> masonf: fullscreen was debatably on the border of something open and closed, another thing where any element can be open or closed
15:57:12 <jarhar> dbaron: maybe fullscreen should be another, shouldnt use open and closed
15:57:21 <jarhar> masonf: it already has :fullscreen so maybe it doesnt need :open
15:57:25 <tantek> does that imply that popover should have its own pseudo?
15:57:35 <dbaron> yes, that's what I was suggesting
15:57:42 <tantek> :popped
15:57:42 <jarhar> masonf: modulo select, details and dialog cases can be disambiguated with attribute selector
15:57:47 <masonf> q?
15:57:49 <masonf> ack dbaron
15:57:50 <masonf> ack masonf
15:58:01 <jarhar> jakea: we can remove the overlap by saying that popover does not work on anything that is otherwise openable
15:58:09 <jarhar> jakea: or we come up with more specific names for different kinds of open
15:58:14 <Brecht_DR> q+
15:58:16 <jarhar> masonf: the only one i want an exception for is dialog
15:58:19 <jarhar> masonf: and im a little fearful
15:58:24 <Brecht_DR> q-
15:58:36 <jarhar> masonf: how we got here with an attribute is that the semantics of the things that are popping up are based on the element
15:58:39 <Brecht_DR> (Mason said it... agree with the dialog)
15:58:46 <jarhar> masonf: if you want the semantics of a details then you should be able to do that
15:58:59 <jarhar> scotto: to be fair details doesnt have a role
15:59:06 <masonf> q?
15:59:09 <jarhar> jakea: should we take this to the csswg then?
15:59:22 <jarhar> masonf: it would be good since we have a lot of good context here,is there anything we agree on?
15:59:34 <jarhar> masonf: david said that fullscreen can apply to any element and therefore it has its own pseuco class
15:59:39 <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.)
15:59:42 <jarhar> masonf: maybe popover should have its own pseudo class
15:59:47 <jarhar> masonf: in addition to supporting open
16:00:02 <jarhar> masonf: popover has an additional one to disambiguate
16:00:02 <jarhar> jakea: whats the use case?
16:00:03 <jarhar> masonf: animations is one of the
16:00:10 <tantek> q?
16:00:25 <jarhar> jhey: you can use something like has, has this popover opened somewhere in the page, stuff like that
16:00:26 <jarhar> jhey: general transition stuff
16:00:39 <flackr> q+
16:00:41 <jarhar> jhey: those are the kind of use cases, tell if something is open
16:00:57 <jarhar> jakea: good point, its useful
16:01:02 <tantek> q+ to support separate pseudo
16:01:07 <jarhar> flackr: you need the state change to transition the trigger away
16:01:14 <masonf> q?
16:01:20 <masonf> ack flackr
16:01:43 <jarhar> 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
16:01:48 <masonf> ack tantek
16:01:48 <Zakim> tantek, you wanted to support separate pseudo
16:01:50 <jarhar> masonf: thats parallel to fullscreen i like it
16:01:58 <jarhar> tantek: +1 to support separate pseudo class
16:02:10 <jarhar> tantek: take it to csswg when there is a specific proposal, that way there is less time spent bikeshedding
16:02:16 <masonf> q?
16:02:17 <jarhar> tantek: lets bikeshed here
16:02:28 <masonf> q?
16:02:32 <jarhar> tantek: there is only :fullscreen, you can use :not to check that its not in fullscreen, good place to start
16:02:33 <JakeA> Proposed resolution: Talk to CSSWG about specific pseudo-class instead of `:open`, such as `:popover` (similar to `:fullscreen`)
16:02:40 <masonf> Proposed resolution: add a :popover pseudo class that applies only to open popovers.
16:03:07 <jarhar> tantek: maybe this is a way of saying that open and closed should be something else completely
16:03:21 <tantek> +1
16:03:47 <jarhar> masonf: maybe :open and :closed is not needed at all
16:03:58 <jarhar> jakea: maybe :open is handy for details and select, selectmenu in particular
16:04:21 <jarhar> jakea: if popover is a different thing then we've removed the overlap so its fine
16:04:34 <JakeA> RESOLVED: Talk to CSSWG about specific pseudo-class instead of `:open`, such as `:popover` (similar to `:fullscreen`)
16:04:49 <Brecht_DR> +1
16:05:30 <dbaron> Zakim, end meeting
16:05:30 <Zakim> As of this point the attendees have been dandclark, flackr, Brecht_DR, JakeA, dbaron, tantek
16:05:33 <Zakim> RRSAgent, please draft minutes
16:05:34 <RRSAgent> I have made the request to generate https://www.w3.org/2023/03/23-openui-minutes.html Zakim
16:05:41 <Zakim> I am happy to have been of service, dbaron; please remember to excuse RRSAgent.  Goodbye
16:05:41 <Zakim> Zakim has left #openui
16:06:41 <dbaron> Present+ gregwhitworth
16:06:46 <dbaron> Chair: gregwhitworth, masonf
16:06:56 <dbaron> Present+ jarhar
16:07:06 <dbaron> Present+ masonf
16:07:21 <dbaron> Present+ xiaochengh
16:07:30 <dbaron> Present+ scotto
16:07:43 <dbaron> Present+ jhey
16:08:04 <dbaron> RRSAgent, please draft minutes v2
16:08:06 <RRSAgent> I have made the request to generate https://www.w3.org/2023/03/23-openui-minutes.html dbaron
16:09:05 <dbaron> Agenda: https://github.com/openui/open-ui/blob/main/meetings/telecon/2023-03-23.md
16:09:05 <dbaron> RRSAgent, please draft minutes v2
16:09:06 <RRSAgent> I have made the request to generate https://www.w3.org/2023/03/23-openui-minutes.html dbaron
16:09:31 <dbaron> yes, that works, there's an icon in the upper right corner now
16:09:35 <tantek> chair: masonf
16:09:44 <tantek> RRSAgent, please draft minutes v2
16:09:45 <RRSAgent> I have made the request to generate https://www.w3.org/2023/03/23-openui-minutes.html tantek
16:09:51 <dbaron> Chair: gregwhitworth, masonf
16:09:51 <tantek> RRSAgent, please draft minutes v2
16:09:52 <RRSAgent> I have made the request to generate https://www.w3.org/2023/03/23-openui-minutes.html tantek
16:10:28 <dbaron> (they split 30 minutes each)
16:10:31 <tantek> RRSAgent, please draft minutes v2
16:10:32 <RRSAgent> I have made the request to generate https://www.w3.org/2023/03/23-openui-minutes.html tantek
16:13:14 <gregwhitworth> RRSAgent, please leave
16:13:14 <RRSAgent> I see no action items