<Levi> +Present Levi Thomason
<Stephanie> +Present Stephanie Stimac
<Levi> Do we also have an open meeting link?
<gregwhitworth> agenda: https://github.com/WICG/open-ui/blob/master/meetings/telecon/2020-06-18.md
<scribe> scribe: melanierichards
<Levi> https://meet.google.com/epz-kwth-ndb
<gregwhitworth> #openui
gregwhitworth: Emilio and CSSWG
wanted to define part within most file inputs, a button.
Basically question of whether or not..how many tab stops should
occur. Could focus on entire control (some browsers with text
and button)...
... common for the file element to solely have a single tab
stop, but there is a question of you could have two, hit tab
again and go to button and open prompt on OS.
<gregwhitworth> https://github.com/WICG/open-ui/issues/107#issuecomment-645035352
gregwhitworth: the work that
Aneesha did, she went thru all the libs that exist and some
OSes to outline the expectations. When she says input, "one tab
stop for entire control", and button means "two tab
stops"
... what I observed, majority is single tab stop
... some had not available in research, Melanie had a point
<gregwhitworth> melanierichards: IE/Edge had two tab stops we heard customer feedback that they would prefer for one tab stop which was primarily for efficiency
<gregwhitworth> melanierichards: this was adhoc, but it was clear feedback
<gregwhitworth> melanierichards: it is interesting for sematic perspective
gregwhitworth: additional thoughts on focus?
Levi: are we talking just about file or other actions
gregwhitworth: if there's more than one action, I think different question
Levi: common in libs to build a component that uploads multiple files, usually get something to retry or remove a file. In that case, single tab stop is not sufficient
gregwhitworth: for sure
... is that in Fluent UI file input?
Levi: no, doesn't have a file input built yet. But if you look thru npm for libraries on file inputs, you'll find that
gregwhitworth: you're correct, X buttons next to ones you want to remove. Or for example, multiple with progress indicators. Not sure how you would ARIA updates for individual ones being uploaded. People's thoughts? Does complicate things
una: disagree w/ multiple tab
stops. Currently no way to type in a file name, never seen
that, even if it looks like you can. You have that visual of
text next to button, you only have one action. I think the
interaction can change once you have files. e.g. multiple files
example. In that case we can add additional points of
focus
... for initial, doesn't make sense to have multiple points of
focus
Levi: yeah, I was speaking about after you have multiple files
una: makes sense, chip group or something
gregwhitworth: think we can resolve on prior to file selection, one tab stop. We could fork on, once they're selected, what do libs do?
<Levi> Vuetify has multiple stops. It also shows multiple file chips when multiple are selected. This is common in UI libs: https://vuetifyjs.com/en/components/file-inputs/#with-chips
gregwhitworth: does the anatomy
end up with a spot for those. The web platform doesn't have a
place for those, but the libs do. We could investigate
further...most likely follow regular focusability
... need anatomy and use case investigations. Worth requesting
anyone who wants to investigate into that work...Emilio's
question was specific to the definition question, I don't want
to assume he wants to own this spec. Anyone want to take this
on and come back w/ anatomy proposal?
... don't have to answer on the call but would be cool to have
someone do that research
<gregwhitworth> Proposed Resolution: When there are no files currently selected there will be one tab stop for the entire file control
gregwhitworth: disagreement?
[silence]
RESOLUTION: When there are no files currently selected there will be one tab stop for the entire file control
gregwhitworth: stemmed from Una
and I's discussion, filtering is such a common problem select.
[missed] was like, that's a combobox. This is trying to figure
out, what's the scope of a select. Does a select offer search
capability, or is that a combobox?
... majority of libs, and rough definition of combobox aligns
with that. However, landscape/rough Twitter poll says they
desire functionality to be there. How it's there is up for
debate. There would be an expectation in select spec, whether
it's an attr or the default, the anatomy would change. Is there
an expectation that you could fitler or search within the
select of a group of options
una: my perspective is filtering mechanism is it's a common use case but not something people always want. For ex, short list where user doesn't know all the options, not going to search, don't know what to search for. But a country list is a long list where they would search...I think it's not default, but is an attribute
masonfreed: input type text with datalist, which is the definition of combobox. Suggestion that are helpful but not required. Search on select is an existing implementation, maybe not well implemented, but you can type ahead and it will take you to the item you typed. Is there a downside of making that more obvious / explicit feature?
gregwhitworth: the first Q, feels like we're trying to distinguish whether typing should occur, it sounds like your def of combobox is you can type something not in options. In my mind, combobox always seems like a wrapper of input and datalist...sounds like that's the first thing I want to land on, people agree filtering in a list should exist. Agree?
[nodding, yes's]
gregwhitworth: would there be an expectation that you should be able to insert text into that that may not exist in an option?
heycam: that's a different control that you have to choose explicit (e.g. with an attribute on select) or create input with datalist
Levi: I look at things of existing design libs, most of them, you can type whatever you like in there, if it returns no options, you could add that value. The danger of avoiding what already exists, if the browser has a wall where people can't go, will use custom ones
gregwhitworth: should the select allow you to insert options that do not exist in an option set? Having an attr that allows additional data entry, or because input/datalist exists, create a new element called combobox
Levi: from my view, thinking of 3rd path, a callback/event that's raise, onAddItem or whatever, this user is trying to submit this item
una: important to differentiate datalist from select. Select is immutable set of options, can't update, where datalist you can...could have an attr, but most use cases for select will not have unexpected values
gregwhitworth: sounds like we have 3 different issues...at minimum we agree there should be filtering capabilities (exists, want to improve on, provide a true input). Default or not a separate question. Is there agreement there that we should change the anatomy such that you could enter text into an input and filter options
Levi: I would say yes
heycam: always available?
gregwhitworth: no, that's another problem.
Levi: can I propose we close on attr after we get consensus?
RESOLUTION: For filtering of a select the anatomy should have an input text box and you type you should see the characters. How you enable that input or if it should be default is the next issue
una: I feel like the dropdown is an opportunity for discovery when you don't know options, in that sense, wouldn't want [missed] to be default...filtering is currently a secret interaction, so I don't think that's saying we're paving cowpaths. One is discovery from a dropdown, pick a photog from 5 names, one is a filterable use case with an expected value, address or country, thats the filterable select. And that's where an optional
attribute makes more sense rather that on by default
[may not have been scribed well, pls fix]
masonfreed: on demand searchbox when you start typing
una: my understanding, a text box that indicates you can start searching and then can type to filter
masonfreed: select that doesn't look like you can type into it, but if you didn't start typing, it wouldn't look like you could search it
gregwhitworth: don't want to get
too much into the look...to your point, we could with those
slotting abilities end up like FF, you click in, at the very
top of the select is where the typed entry is
... heycam correct if wrong?
heycam: just discovered it by reading the issue :)
gregwhitworth: is this capability on by default or is there an attribute?
una: I want to differentiate filtering, filter will remove the other results that don't match the other results that don't match. Whereas big dropdown open, type M, go down to those states, those are different
gregwhitworth: so then maybe we don't say "filter". Author will provide better searching, whether they provide [different UI / keystroking] will be up to author on how that will occur
Levi: Una and I are saying there's two modes, searchable and non-searchable?
gregwhitworth: 3, the scroll into view you might also notwant
una: saying same thing, existing f(x) where you can drop down to the option in the list. That's not filtering. Filter is an attribute. Wouldn't conflate keyboard interactions, they would be different
Levi: if you had filtering on, the jump wouldn't happen unless someone abused the element
gregwhitworth: agreement on
attributes? Let's spin up new issue on attr and spin up what
that means
... would love help on that if anyone has time
... when Bo and I talking, should it do pattern matching, or to
Levi's point, we'll provide something out of the box and you
can override
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/have to build/have to choose explicit (e.g. with an attribute on select)/ Present: Greg Whitworth Cameron McCormack melanierichards Levi Thomason Rob Eisenberg una nicholasrice Found Scribe: melanierichards Inferring ScribeNick: melanierichards Agenda: https://github.com/WICG/open-ui/blob/master/meetings/telecon/2020-06-18.md WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]