Meeting minutes
<Jem> https://
<Jem> https://
Setup and Review Agenda
Jem: Next meeting: June 18
Jem: July 4th is a holiday in the US
Matt_King: That falls on a Thursday this year
Matt_King: Do we want to meet on Tuesday, July 2?
Jem: I am taking the week of July 1 off for vacation
arigilmore: I will be out the week after that
jugglinmike: Howard and I will also be out the week of July 8
Jem: I'm out on July 9th
Matt_King: okay, we'll plan on meeting on July 2 but cancelling the July 9 meeting
Jem: Any requests for change to agenda?
jongund: I'd like to discuss a new feature for skipTo.js
Publication planning
Matt_King: We're shooting for June 25th as a next publication date
Matt_King: Jon's "quality review" pull request is awaiting review from howard-e
Matt_King: w3c/
Matt_King: It looks like there are no reviewers, actually.
Matt_King: I'm going to assign howard-e for code review
Matt_King: the other things for this milestone are either later in the agenda or not ready for review, yet
Change high contrast system color in ratings slider
github: w3c/
jongund: I changed the system color link text to "buttontext". It just makes our widgets look more like form controls than links
Matt_King: why are two files changed?
jongund: I also had to change the cspell configuration. cspell checks CSS files for spelling
Matt_King: That seems undesirable
howard-e: I can look into that
Matt_King: Does this color change impact all contexts? Or only high-contrast mode?
jongund: Only high-contrast mode
jongund: Depending on how you test it, you don't necessarily need Windows
jongund: In Chrome, for instance, you can use the developer tools to simulate high-contrast mode
jongund: This probably won't affect macOS users
jongund: The only place I know this pull request will make a difference is in Windows
Matt_King: So the pull request should have screenshots of the difference (before and after), and also instructions for how a reviewer can observe the difference themself
Jem: I can review once jongund adds that information
Matt_King: Okay, I'll assign you, then
Matt_King: is this a change you were just trying out for the one slider? Do you think it should be applied to the other examples if people like it?
jongund: Yes, I think we should use it elsewhere. Though we only use the "forced colors" media query in one other pattern--feed. I'd also like to add it to other patterns
Mouse behavior differences between Select-only and editable combobox
github: w3c/
Matt_King: Curt_Bellew did some work on this
<Jem> w3c/
Matt_King: When someone changes which option is highlighted in the list of options using the keyboard. So the value isn't actually set at this moment. Then, they click outside of the combobox
Matt_King: Because the click closes the dropdown, should that impact the selected value?
Matt_King: In other words, should clicking outside be treated like "enter"/"tab" or like "escape"?
Matt_King: So we were wondering what browsers do for standard selects
Matt_King: Chrome and Firefox on macOS both return to the initial value, (treating it like "escape")
Matt_King: Windows does the opposite
Matt_King: This is not what I was expecting!
Matt_King: If we were going to have our combobox mimic the behavior based on the platform... We could do that, but it feels batty to me
[general discussion]
jongund: I don't think the behavior of the APG's combobox should be operating-system dependent
Matt_King: The select-only combobox behaves like Windows. The auto-complete combobox behaves like macOS.
Matt_King: So we have inconsistencies between our examples
Mark_McCarthy: I agree with jongund. We should choose one operating system to mimic
Bryan_Garaventa: I think the two examples should match
jongund: It seems like clicking outside the box is more like hitting "escape", conceptually
Matt_King: I agree. If the user is expressing an intent, it seems like it's "get me out of here"
Matt_King: (None of this affects screen reader users because we can't click outside of the box, even if we wanted to.)
jugglinmike: It may be that some users (particularly sighted users) don't recognize that highlighting an item is not the same as selecting it. From that perspective, it would be surprising for selection *not* to occur after clicking outside
Matt_King: It sounds like collectively, we have a preference for making this behave like "escape" (which is how the native element behaves on macOS)
Jem: In my opinion, I think it's important to have consistency in APG.
Matt_King: In terms of prioritization, I am adding the "bug" label to this issue, now
Matt_King: In terms of the severity of the bug, this is clearly not a blocking problem. It seems like a sub-3 kind of bug. It's an inconsistency, but it's an inconsistency that's hard to find
Matt_King: I'm going to label this "P3" for now; does anyone disagree?
Jem: I really don't like the inconsistency, but I'm okay with that
Select-only combobox enter key behavior
github: w3c/
Matt_King: this is another inconsistency within the APG and also an inconsistency with the native "select"
Matt_King: I don't know why we have the "enter" key expanding. Maybe it's because that's what menu buttons do
Matt_King: Do people think we should remove the "Enter to open" on the select-only combobox example?
Bryan_Garaventa: I've used that in the past
jongund: Enter has not been a past default action
Matt_King: Because our combobox is collapsed by default and because it's select-only, it has a lot of similarities with menu button
Matt_King: I have questions about the visual design of the select-only combobox
Matt_King: Does it look like a button? And can you click on a down-arrow icon to expand it? Or does it even have a down-arrow icon?
arigilmore: It has an arrow, but you can click anywhere on the box to open it
arigilmore: It's styled more like a button
Matt_King: So it looks more like a menu button than an input field
Matt_King: If you can click to expand it, then I'm thinking that pressing "enter" to expand it is analogous
Bryan_Garaventa: I would agree with that
Mark_McCarthy: Me too. As a keyboard user, it seems like it can't hurt
Matt_King: Okay, we'll stick with the "enter" key behavior and treat this as an editorial problem
Matt_King: We'll make a change to the text of the "keyboard" section of the combobox pattern
skipTo.js feature change
jongund: I spoke with some folks at Walmart about possibly adopting skipTo.js
jongund: They have a feature request which is to give feed-forward about where it will take you
Matt_King: That's exactly what we did at Facebook, and we got positive feedback from the community
Matt_King: But we didn't have developer interest in supporting it in the long term, so we eventually removed it
jongund: Would you be interested in talking with them?
Matt_King: Sure
Mark_McCarthy: I would, too
jongund: Thank you so much!
jongund: I'll make a prototype that we can review at some future date