IRC log of openui on 2023-03-23
Timestamps are in UTC.
- 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