Meeting minutes
<gregwhitworth> github-bot, take up openui/
[combobox] Should we allow a button child to control the dropdown?
<github-bot> OK, I'll post this discussion to https://
lukew: for selectlist, one of the use cases was a split button design, so based on the type attribute you could choose what it controls
lukew: my question is if we should allow that also for combobox?
masonf: I'm of two minds… first thought: haven't seen a component like that (text input + button to show dropdown + button that does something else), that would make me think 'no'
masonf: but on the other hand, it would make sense to have a similar approach between selectlist and combobox
gregwhitworth: me and sudheer discussed this yesterday
gregwhitworth: the current select kind of pseudo-behaves in this way, with an arrow
gregwhitworth: issue would be focus management, when someone would want to type and use the button
gregwhitworth: technically you would invoke the button but would also expect to type on the combobox… select already does this today
gregwhitworth: feels like a bad paradigm to introduce, given the key use case of the combobox
gregwhitworth: split button feels like it introduces a third problem, theoretically feasible
masonf: accessibility is the key thing
<masonf> buttons are to combobox as soda is to calzone
scotto_: just because I like two things, doens't mean I need them in the same thing. We can have things that are siblings, that can be fine
<scotto_> we were going to put soda into calzones
una: missed first bit, sounded like we were going to remove split button in combobox? seems to be like this is a common use case we should be solving for?
gregwhitworth: it was one of the things where we won't block it, technically it would work, but just worried that we would have three different focus behaviour and this is a pattern I don't think we see a lot in the wild?
una: I've seen them on dropdowns for sure, usually it's a menu triggered by the button
una: one example is amazon.com, the main search bar there has a split button that is basically a search input but on the left of that a dropdown that has departments and ways to filter down search
una: but that could be a visual thing only, built technically out of multiple components
gregwhitworth: great example… yes seems like that could be multiple components that are visually grouped together
masonf: would say the one on amazon is a combobox and a select
una: yes, it's interesting… it's multiple components and it looks visually like one piece
<brecht_dr> +1 on not introducing split button for combobox in general, but allowing this for other UI elements such as selectlist
gregwhitworth: not sure about proposed resolution… sounds like we won't actually block split buttond?
lukew: I think it wouldn't make sense to have type=selectlist inside of combobox
gregwhitworth: like on amazon, when you invoke text element, is when the popup target is invoked… whatever that needs to be we should update it to
masonf: I would propose two things: we should rename that to type=select… for this issue, based on this discussion, any button that is inside the combobox should trigger the popup, would also eliminate the need to pick another attribute
gregwhitworth: would it be first or any?
lukew: I think any?
una: I think it's hard to have this discussion without having any examples of this
una: does anyone know of an example of a combobox that has a split button?
gregwhitworth: no… maybe this is where we're going back… combobox should still be theoretically extensible
gregwhitworth: I should theoretically be able to pull off this behaviour with a button type=select
lukew: that's what I'm leaning towards… let buttons just behave like buttons would normally behave, without extra attributes
masonf: you mean any button inside combobox triggers the popover?
lukew: no only that button would do what it would nornally do, including nothing
<masonf> Proposed resolution: any button inside a combobox triggers the popover.
gregwhitworth: problem with 'any'… if author adds tags and the tag can be deleted with an 'x' button… would that cause issues?
gregwhitworth: most design systems have a pills/tags element where the individual elements can be deleted… and that could be used and need to be removeable in a combobox, would that open/close popup?
una: or if you had predefined answers
una: or an accordion of options that could be hidden
masonf: none of these sound like comboboxes, more like very fancy selects?
gregwhitworth: could totally be a combobox
gregwhitworth: eg when tagging issues on stackoverflow
masonf: but those pills can't be inside of the text input, right? text input is text?
gregwhitworth: we might need a new issue for this?
una: even in the amazon example… the combobox has a search bar with some predefined options… the first few options are things you already searched for and you can press an X that removes that suggestion
masonf: the additional things you can do are in the option not in the text box?
masonf: allowing for more than just text in the text box could open a whole can of worms
keithamus: on GitHub, if you click on a repository that you own and click the cog you get pills in the section where you can add topics… our accessibility team said it was an inaccessible pattern
keithamus: you effectively have a list of tokens/topics before your textareas, your textarea moves, the topic gets added as a list
flackr: the Gmail compose box has a similar pattern, addresses become pills as you complete them
masonf: not discounting these are real things… just wonder as we're building a web standard that allows for building these things, how can we do it, what does it return, just the text or also the pills?
keithamus: the pills thing seems to be like a totally different form control that we might need to spec differently?
masonf: sounds like a form associated custom element
gregwhitworth: sounds like this problem would require us to solve multi select / combobox
gregwhitworth: the amount of scenarios in which pills being in the text input… by all means if you say it only takes text, we probably found another gap in the platform?
gregwhitworth: people are probably going to go do this
gregwhitworth: this issue is probably tangential to whether split button works in combobox
lukew: you don't necessarily need the input to have children… you could have them as children to the combobox element
lukew: that would also solve the issue of having interactive content as children, that's kind of allowed
lukew: though depends on whether combobox counts as interactive
lukew: if we just say all buttons triggger it, it limits use cases, it means if you want a button that doesn't open it, you have to preventDefault, which is an ordeal
gregwhitworth: whatever select has defined, we should probably do it for combobox too, not arbitrary block it, and look at any gaps there may be
masonf: maybe type=popover, that explains what it is going to do
masonf: and could be shared between combobox and select
gregwhitworth: I like that, feels less arbitrary than having type=combobox and type=select
gregwhitworth: so we probably come up with a name that applies to selectlist and combobox
<masonf> Proposed resolution: any button with type=popover inside a combobox will trigger the popover. Other buttons will not.
gregwhitworth: maybe change to “combobox or select” so thatit applies to both ?
<masonf> Proposed resolution: for stylable <select> use <button type=popover>. For combobox, any button with type=popover inside a combobox will trigger the popover. Other buttons will not.
lukew: I don't think limiting the type actually makes sense
lukew: may come back to that in a separate issue
<lukew> +1
+1
RESOLUTION: for stylable <select> use <button type=popover>. For combobox, any button with type=popover inside a combobox will trigger the popover. Other buttons will not.
<gregwhitworth> github-bot, take up w3c/
<github-bot> gregwhitworth, I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: openui/open-ui whatwg/html.
masonf: the history: this started out as a proposal for a CSS property and value, CSS WG discussed this many months ago but concluded for various reasons that this would be an attribute on the element
<gregwhitworth> many months === over 2 years :P
masonf: the reasons included: for some engines it was hard to condition the contents of Shadow DOM based
masonf: there is also a interop issue
masonf: we'd need a way to avoid breakage when someone does * { appearance: base } which would opt them in to base appearance for everything on the page… doing it in CSS makes it too easy to accidentally trigger that
masonf: last concern: can't condition your CSS rules based on the value of the property
masonf: some pushback was that it feels more like a CSS thing, related to styling, so people wondered why shouldn't it be in CSS? so recently was brought back to CSSWG to re-examine if it could be done in CSS
masonf: one way would be a pseudo class that only works if a given browser supports base styling for that control
masonf: I'm curious from folks here, which way feels best?
keithamus: CSS style queries are being proposed, does that not solve the issue?
keithamus: with the attribute… you would have a select element with attribute of base, so the literal text to be interpreted would potentially be circular?
keithamus: what is the different between select base and select space base?
keithamus: if we're jupmping through these hoops and dealing with all the workarounds, but if we lose the ergonomic benefits by having an attribute it feels somewhat backwards?
una: one thought… don't think we should rely on style queries… yes it exists but don't want it to be a blocker
una: I do feel like this makes sense in CSS if we're choosing one or the other… the place you go to style things, not sure it's that much more work
una: and wouldn't want to rely on a different CSS feature to ship
una: for consistency… CSS seems like the place for a feature like this
dbaron: I don't think style queries support this particular thing, they ask if you styled something in a specific way, not if it actually works on that thing?
masonf: independently we need a pseudo class for knowing whether something is supported
masonf: I think people would like to be able to write style rules that only apply when the element actually supports appearance base?
gregwhitworth: I'm curious if it still stands… that the DOM is created prior and we need to change DOM structure?
gregwhitworth: ironically the decision to go with <select> would make this trickier
gregwhitworth: from a performance perspective, is there a non trivial amount of overhead for going back between style and dom ?
gregwhitworth: if we wait for style calc it could have the negative ramification of having to go backwards?
gregwhitworth: performance would be my argument for the attribute instead of style
gregwhitworth: all the new ones could be base by default and you can upgrade to user agent
una: clarifying question… would there be dom changes based on style?
gregwhitworth: shadow dom
gregwhitworth: as I understand from a few years ago… when input type=color came out we mapped it to the native Windows color picker
gregwhitworth: now everyone agreed on the anatomy and base styles… those styles only matter if all of it is completely standardised
gregwhitworth: if I have to completely rip it out, that creates a circular impact
masonf: I hear the concern about performance… I think the only real answer is to test it and se what happens
brecht_dr: from a CSS developer standpoint… it's always been weird for me that appearance base never was a thing, you would expect it a thing… it would be great to have something like this in CSS, not just for selects but in general
brecht_dr: I think for authors this should be made easy to use
brecht_dr: so +1 to this being in CSS
masonf: I'm personally ok with the default being UA style and you opt in yourself; if you can opt yourself into base style without a performance hit (we need to test it and deal with it when it comes to it, seems solveable to me)
masonf: I personally think it should not be appearance:base, but appearance:base-select, I worry about developers adding *{appearance:base} and making lots of things base by accident
dandclark: agree with what masonf just said, to have specific appearance values for each control
dandclark: what happens if I'm on iOS where the default select is very different and uses a OS specific flyout thing and I add a datalist and some CSS etc… what would happen if I forget to specify base-select appearance?
dandclark: would I end up with a mix of behaviours?
masonf: great question… my sense is the new parsing behaviour of not throwing datalist etc needs to work, apart from the new base functionality
masonf: user agent is still free to use their native select list
masonf: if you're not in base mode
dandclark: we talked before about the opt in behaviour… including things like flyout being able to escape the bounds of the browser window… would base be the switch for controls like that?
masonf: adding datalist or button adds you to the new DOM structure and new popover behaviour
dandclark: but thinking about the iOS styling in particular… seems kind of incompatible ?
gregwhitworth: that's not styling
masonf: I think we have an issue for it… whether or not it's ok for the UA to do its own thing
masonf: was also imagined for other/future form factors like watch faces etc
una: I feel like framing this as appearance is quite misleading
una: as there are actual DOM changes that happen when you decide to opt in to the user agent / system UI
una: feel like if we're using appearance base there shouldn't be DOM changes, just visual changes
una: what we're talking about here is structural changes, that we're trying to describe in the context of CSS… ergonomically… I'd like to be able to say all of my selects need to be appearance base
una: but this isn't really styling issue, but more of a system component kind of thing
una: feels like we might want to separate that discussion
una: if you want to pop out to the iOS select, that's a structural change
lukew: I don't think it makes sense of this as purely an appearance CSS property
lukew: it is likely that this could also change accessibiliy semantics, for instance
lukew: it makes more sense for it to be a separate element or attribute
lukew: would have the annoyance of having to opt in to every element… maybe a <meta> tag or something could work here where you could globally opt in for specific elements
lukew: I think it makes more sense to have it in HTML than CSS
<masonf> 4 minutes left, 4 people on the queue. 1 minute per person.
gregwhitworth: right now we're just talking about select… let's think about all the other elements we'd like to tackle
gregwhitworth: if we introduce the <switch> element, in order to have interoperable styles, you know also have to do appearance:base-switch?
gregwhitworth: for select, we're doing a lot
brecht_dr: I agree the issue is more than just the appearance
brecht_dr: if you would use appearance it would be strange to scope it just to get around people using a * selector
masonf: I'm glad you don't do * stuff, but lots of people do… which we sadly have to deal with as browser engineers
masonf: re: DOM structure vs visual… the presence of datalist or button inside of the select opts you in to the new DOM structure, and the appearance:base purely does the visual
masonf: maybe that would be a solution?
gregwhitworth: let's take this up next week as we're at time
👋