[combobox] Should we allow a button child to control the dropdown?

[lukewarlow]

For selectlist we allow designs such as split buttons where you have a main button and then a split button to control the dropdown.

Should we allow a split button option for combobox?

[css-meeting-bot]

The Open UI Community Group just discussed [combobox] Should we allow a button child to control the dropdown?, and agreed to the following:

• RESOLVED: 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.

The full IRC log of that discussion

<hdv> 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
<masonf> q+
<hdv> lukew: my question is if we should allow that also for combobox?
<gregwhitworth> q+
<hdv> 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'
<hdv> masonf: but on the other hand, it would make sense to have a similar approach between selectlist and combobox
<hdv> gregwhitworth: me and @@@ discussed this yesterday
<hdv> gregwhitworth: the current select kind of pseudo-behaves in this way, with an arrow
<hdv> gregwhitworth: issue would be focus management, when someone would want to type and use the button
<scotto_> q+
<hdv> gregwhitworth: technically you would invoke the button but would also expect to type on the combobox… select already does this today
<hdv> gregwhitworth: feels like a bad paradigm to introduce, given the key use case of the combobox
<hdv> gregwhitworth: split button feels like it introduces a third problem, theoretically feasible
<hdv> masonf: accessibility is the key thing
<gregwhitworth> q?
<gregwhitworth> ack masonf
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack scotto_
<una> q+
<gregwhitworth> s/@@@/sudheer
<gregwhitworth> ack una
<masonf> buttons are to combobox as soda is to calzone
<hdv> 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
<scotto_> q+
<hdv> 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?
<masonf> q+
<masonf> ack scott
<hdv> 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?
<hdv> una: I've seen them on dropdowns for sure, usually it's a menu triggered by the button
<hdv> 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
<hdv> una: but that could be a visual thing only, built technically out of multiple components
<gregwhitworth> q?
<gregwhitworth> ack masonf
<hdv> gregwhitworth: great example… yes seems like that could be multiple components that are visually grouped together
<hdv> masonf: would say the one on amazon is a combobox and a select
<hdv> una: yes, it's interesting… it's multiple components and it looks visually like one piece
<masonf> q?
<brecht_dr> +1 on not introducing split button for combobox in general, but allowing this for other UI elements such as selectlist
<hdv> gregwhitworth: not sure about proposed resolution… sounds like we won't actually block split buttond?
<hdv> lukew: I think it wouldn't make sense to have type=selectlist inside of combobox
<hdv> 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
<hdv> 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
<hdv> gregwhitworth: would it be first or any?
<hdv> lukew: I think any?
<una> q+
<gregwhitworth> ack una
<hdv> una: I think it's hard to have this discussion without having any examples of this
<hdv> una: does anyone know of an example of a combobox that has a split button?
<hdv> gregwhitworth: no… maybe this is where we're going back… combobox should still be theoretically extensible
<hdv> gregwhitworth: I should theoretically be able to pull of this behaviour with a button type=select
<hdv> s/of/off
<hdv> lukew: that's what I'm leaning towards… let buttons just behave like buttons would normally behave, without extra attributes
<hdv> masonf: you mean any button inside combobox triggers the popover?
<hdv> 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.
<hdv> gregwhitworth: problem with 'any'… if author adds tags and the tag can be deleted with an 'x' button… would that cause issues?
<hdv> 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?
<hdv> una: or if you had predefined answers
<hdv> una: or an accordion of options that could be hidden
<hdv> masonf: none of these sound like comboboxes, more like very fancy selects?
<hdv> gregwhitworth: could totally be a combobox
<hdv> gregwhitworth: eg when tagging issues on stackoverflow
<hdv> masonf: but those pills can't be inside of the text input, right? text input is text?
<hdv> gregwhitworth: we might need a new issue for this?
<keithamus> q+
<hdv> 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
<hdv> masonf: the additional things you can do are in the option not in the text box?
<hdv> masonf: allowing for more than just text in the text box could open a whole can of worms
<flackr> q+
<gregwhitworth> ack keithamus
<hdv> keithamus: on GitHub, if you click on a repository that you own and click the cog you get pills… our accessibility team said it was an inaccessible pattern
<hdv> keithamus: you effectively have a list of tokens/topics before your textareas, your textarea moves, the topic gets added as a list
<hdv> s/pills/pills in the section where you can add topics
<masonf> q+
<gregwhitworth> ack flackr
<hdv> flackr: the Gmail compose box has a similar pattern, addresses become pills as you complete them
<gregwhitworth> q+
<hdv> 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?
<hdv> keithamus: the pills thing seems to be like a totally different form control that we might need to spec differently?
<gregwhitworth> ack masonf
<hdv> masonf: sounds like a form associated custom element
<hdv> gregwhitworth: sounds like this problem would require us to solve multi select / combobox
<hdv> 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?
<brecht_dr> q+
<hdv> gregwhitworth: people are probably going to go do this
<hdv> gregwhitworth: this issue is probably tangential to whether split button works in combobox
<hdv> q?
<gregwhitworth> ack gregwhitworth
<hdv> lukew: you don't necessarily need the input to have children… you could have them as children to the combobox element
<hdv> lukew: that would also solve the issue of having interactive content as children, that's kind of allowed
<hdv> lukew: though depends on whether combobox counts as interactive
<brecht_dr> q-
<hdv> 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> q+
<hdv> 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
<hdv> masonf: maybe type=popover, that explains what it is going to do
<hdv> masonf: and could be shared between combobox and select
<hdv> gregwhitworth: I like that, feels less arbitrary than having type=combobox and type=select
<hdv> 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.
<hdv> 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.
<hdv> lukew: I don't think limiting the type actually makes sense
<hdv> lukew: may come back to that in a separate issue
<lukew> +1
<hdv> +1
<masonf> RESOLVED: 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.
<hdv> 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
<hdv> masonf: the reasons included: for some engines it was hard to condition the contents of Shadow DOM based
<hdv> masonf: there is also a interop issue
<keithamus> q+
<hdv> 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
<gregwhitworth> q?
<gregwhitworth> ack gregwhitworth
<hdv> masonf: last concern: can't condition your CSS rules based on the value of the property
<hdv> 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
<hdv> masonf: one way would be a pseudo class that only works if a given browser supports base styling for that control
<hdv> masonf: I'm curious from folks here, which way feels best?
<gregwhitworth> ack keithamus
<hdv> keithamus: CSS style queries are being proposed, does that not solve the issue?
<gregwhitworth> q+
<una> q+
<gregwhitworth> ack gregwhitworth
<gregwhitworth> q+
<hdv> 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?
<hdv> keithamus: what is the different between select base and select space base?
<masonf> q++
<masonf> q--
<masonf> q-+
<hdv> 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?
<gregwhitworth> ack una
<gregwhitworth> ack gregwhitworth
<gregwhitworth> q+
<hdv> una: one thought… don't think we should rely on style queries… yes it exists but don't want it to be a blocker
<brecht_dr> q+
<hdv> 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
<hdv> una: and wouldn't want to rely on a different CSS feature to ship
<hdv> una: for consistency… CSS seems like the place for a feature like this
<gregwhitworth> ack dbaron
<hdv> 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?
<hdv> masonf: independently we need a pseudo class for knowing whether something is supported
<hdv> masonf: I think people would like to be able to write style rules that only apply when the element actually supports appearance base?
<hdv> gregwhitworth: I'm curious if it still stands… that the DOM is created prior and we need to change DOM structure?
<hdv> gregwhitworth: ironically the decision to go with <select> would make this trickier
<masonf> q+
<dandclark> q+
<hdv> gregwhitworth: from a performance perspective, is there a non trivial amount of overhead for going back between style and dom ?
<hdv> gregwhitworth: if we wait for style calc it could have the negative ramification of having to go backwards?
<una> q+
<lukew> q+
<hdv> gregwhitworth: that would be my argument for the attribute instead of style
<hdv> gregwhitworth: all the new ones could be base by default and you can upgrade to user agent
<hdv> s/that/performance
<hdv> una: clarifying question… would there be dom changes based on style?
<hdv> gregwhitworth: shadow dom
<hdv> gregwhitworth: as I understand from a few years ago… when input type=color came out we mapped it to the native Windows color picker
<hdv> gregwhitworth: now everyone agreed on the anatomy and base styles… those styles only matter if all of it is completely standardised
<hdv> gregwhitworth: if I have to completely rip it out, that creates a circular impact
<gregwhitworth> q?
<hdv> masonf: I hear the concern about performance… I think the only real answer is to test it and se what happens
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack brecht_dr
<hdv> 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
<hdv> brecht_dr: I think for authors this should be made easy to use
<hdv> brecht_dr: so +1 to this being in CSS
<gregwhitworth> ack masonf
<hdv> 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)
<hdv> 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
<masonf> q?
<gregwhitworth> ack dandclark
<gregwhitworth> q+
<brecht_dr> q+
<hdv> dandclark: agree with what masonf just said, to have specific appearance values for each control
<hdv> 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?
<hdv> dandclark: would I end up with a mix of behaviours?
<hdv> masonf: great question… my sense is the new parsing behaviour of not throwing datalist etc needs to work, apart from the new base functionality
<hdv> masonf: user agent is still free to use their native select list
<hdv> masonf: if you're not in base mode
<jarhar> q?
<hdv> 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?
<hdv> masonf: adding datalist or button adds you to the new DOM structure and new popover behaviour
<hdv> dandclark: but thinking about the iOS styling in particular… seems kind of incompatible ?
<hdv> gregwhitworth: that's not styling
<hdv> masonf: I think we have an issue for it… whether or not it's ok for the UA to do its own thing
<hdv> masonf: was also imagined for other/future form factors like watch faces etc
<gregwhitworth> ack una
<masonf> q?
<hdv> una: I feel like framing this as appearance is quite misleading
<hdv> una: as there are actual DOM changes that happen when you decide to opt in to the user agent / system UI
<masonf> q+
<hdv> una: feel like if we're using appearance base there shouldn't be DOM changes, just visual changes
<hdv> 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
<hdv> una: but this isn't really styling issue, but more of a system component kind of thing
<hdv> una: feels like we might want to separate that discussion
<jarhar> q+
<hdv> una: if you want to pop out to the iOS select, that's a structural change
<gregwhitworth> ack lukew
<hdv> lukew: I don't think it makes sense of this as purely an appearance CSS property
<hdv> lukew: it is likely that this could also change accessibiliy semantics, for instance
<keithamus> q+
<hdv> lukew: it makes more sense for it to be a separate element or attribute
<hdv> 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
<hdv> I think it makes more sense to have it in HTML than CSS
<hdv> s/I think/lukew: I think
<masonf> 4 minutes left, 4 people on the queue. 1 minute per person.
<hdv> gregwhitworth: right now we're just talking about select… let's think about all the other elements we'd like to tackle
<hdv> gregwhitworth: if we introduce the <switch> element, in order to have interoperable styles, you know also have to do appearance:base-switch?
<hdv> gregwhitworth: for select, we're doing a lot
<gregwhitworth> ack gregwhitworth
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: I agree the issue is more than just the appearance
<gregwhitworth> Zakim, close queue
<Zakim> ok, gregwhitworth, the speaker queue is closed
<hdv> brecht_dr: if you would use appearance it would be strange to scope it just to get around people using a * selector
<gregwhitworth> ack masonf
<hdv> masonf: I'm glad you don't do * stuff, but lots of people do… which we sadly have to deal with as browser engineers
<hdv> 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
<hdv> masonf: maybe that would be a solution?
<hdv> gregwhitworth: let's take this up next week as we're at tiome
<keithamus> q-
<hdv> s/tiome/time
<hdv> 👋
<gregwhitworth> Zakim, end meeting

[mfreed7]

Quick note about the notes above: they also include the discussion of w3c/csswg-drafts#5998.