- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Jul 2020 14:58:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Open UI presentation`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Open UI presentation<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5350<br> <TabAtkins> [greg presents]<br> <nigel> s/jfkthame: inline-box-height?/nigel: inline-box-height?<br> <TabAtkins> gregwhitworth: I met with ARIAWG 3 weeks ago about this; after last weeks' discussiona bout accent-color, and previous about file-input button, I thought it woudl be good to go over the OPen UI CG and what it's doing.<br> <TabAtkins> gregwhitworth: Hopefully leave time for discussion/comments/etc after.<br> <TabAtkins> gregwhitworth: Edge and Chrome worked to update their form controls in Chromium to update a11y, touch, and a visual refresh.<br> <TabAtkins> gregwhitworth: Gave talks about this with Nicole Sullivan, the Chrome half of things.<br> <TabAtkins> gregwhitworth: Here's high-contrast working, for example.<br> <TabAtkins> [shows slide of some widgets in high-contrast mode]<br> <TabAtkins> gregwhitworth: Lot of people when we show them get excited we've spent time on the built-ins.<br> <TabAtkins> gregwhitworth: A common question afterwards is "how come when i'm navigating the web I don't see these controls?"<br> <TabAtkins> gregwhitworth: Lot of reasons, onion-peeling things.<br> <TabAtkins> gregwhitworth: Did a lot of surveys.<br> <TabAtkins> gregwhitworth: Wanted to understand why webdevs recreate form controls.<br> <TabAtkins> gregwhitworth: 37% is changing the papearance, 32% is more functionality, 27% is browser inconsistency, 3% is a11y, 2% is other<br> <TabAtkins> gregwhitworth: These are consistent answers.<br> <TabAtkins> gregwhitworth: There are low-hanging fruit in each category, we think<br> <TabAtkins> gregwhitworth: A big consistent one is browser inconsistencies.<br> <TabAtkins> gregwhitworth: Like Chromium's color input<br> <TabAtkins> gregwhitworth: The site would say "what'st he lowest common denominator"<br> <TabAtkins> gregwhitworth: Chromium historically is the native Windows color widget, which is real old-school and W95-looking. And if it didn't give them waht they needed, they'd throw it away and do their own.<br> <TabAtkins> gregwhitworth: So if there isn't interop, it doesn't matter what we ultimately introduce across browsers.<br> <TabAtkins> gregwhitworth: So if we can't standardize across many respects, the rest of the work is fruitless. So that's a big reason Open UI came into existence.<br> <TabAtkins> gregwhitworth: The top 10 list ofr recreated form controls<br> <TabAtkins> gregwhitworth: select, checkbox, date, radio, file, progress, button, dialog, textarea, text<br> <TabAtkins> gregwhitworth: Workhorses of the web<br> <TabAtkins> gregwhitworth: button/textarea/text are near the end, as they're less problematic in general<br> <TabAtkins> gregwhitworth: And more importantly, we asked which is most frustrating, and select beats everything by a *lot*<br> <TabAtkins> (42% vs 17% for next place)<br> <TabAtkins> gregwhitworth: You see complex ones at the forefront; simpler ones seem less frustrating.<br> <TabAtkins> gregwhitworth: I think it's become so status quo that this problem is part of the web<br> <TabAtkins> gregwhitworth: So people come up and say "shoudl the platform even invest in this?"<br> <TabAtkins> gregwhitworth: I often hear there's a bunch of component libraries, the big sites have big teams focusing on the same stuff browser devs do, so all these fundamentals aren't gaps on those top sites.<br> <fantasai> (42.7% select, 17.3% date, 9.3% file, 8.0% checkbox, 6.7% radio, 4.0% range, <3% the rest<br> <fantasai> )<br> <TabAtkins> gregwhitworth: We looked at a bunch of menu/popup libraries. Spent 30min, found *numerous* a11y problems, can't use in keyboard, etc<br> <TabAtkins> gregwhitworth: This is 8 months old, hopefully a little better today.<br> <TabAtkins> gregwhitworth: I tested high-contrast but didn't show here; due to the checkbox/radio hackarounds, high-contrast would often make the entire form disappear. That's extra concerning.<br> <TabAtkins> gregwhitworth: In addition to this, I spoke with partners, major sites, component libs, ssg, pretty much everybody I could<br> <TabAtkins> gregwhitworth: All of them had no desire to rebuild these things.<br> <TabAtkins> gregwhitworth: My fave quote is us asking "would you leverage these if the platform gave better ones, or would you keep using your own?" and someone's VP said "yes, dropdowns aren't our product"<br> <TabAtkins> gregwhitworth: Another project, I was talking to the component engineer leading the dropdown, and they pinged me asking for select behind a flag, because they want to stop owning that component; it's just always buggy and annoying.<br> <TabAtkins> gregwhitworth: So there's obviously a hunger and desire for better natives.<br> <TabAtkins> gregwhitworth: So this is an opportunity for us.<br> <TabAtkins> gregwhitworth: Don't want to pretend this is new. Rossen, when we worked together, emphasized this has been tried many times before.<br> <TabAtkins> gregwhitworth: The way I tried to frame this is...<br> <TabAtkins> gregwhitworth: A designer builds out a new control design.<br> <TabAtkins> gregwhitworth: Recall the earlier problem zones, the spot that people spend the most time on is often a11y<br> <TabAtkins> gregwhitworth: And then ultimately we make a spec.<br> <TabAtkins> gregwhitworth: Literally everyone is doing this, including browsers and OSes.<br> <TabAtkins> gregwhitworth: I got OS devs saying "yeah, this is web-specific, but it overlaps a ton with our designs as well"<br> <TabAtkins> gregwhitworth: So I view Open UI as very similar to how we entered Chromium.<br> <TabAtkins> gregwhitworth: We started exposing certain parts for certain things, we saw devs start adopting.<br> <TabAtkins> gregwhitworth: But we haven't yet taken a step back and started holistically talking about controls in general.<br> <TabAtkins> gregwhitworth: There is not a desire to lock things in palce to stifle innovation in UI, but we do want to pave cowpaths as possible.<br> <TabAtkins> gregwhitworth: And would like there to be a single source of truth for like "what makes a select"<br> <TabAtkins> gregwhitworth: Linked at the end here is a massive explainer<br> <TabAtkins> gregwhitworth: Starts digging into the model that OPen UI leverages to attack the problem<br> <TabAtkins> gregwhitworth: We started with the select, but realized quickly we were actually defining a more general term, which is "what is a control?"<br> <TabAtkins> gregwhitworth: It was pointed out that controls follow an NPC(sp?) model<br> <TabAtkins> s/NPC/MVC/<br> <TabAtkins> gregwhitworth: As you manipulate the input, the model changes and influences the view.<br> <TabAtkins> gregwhitworth: So we wnat Open UI to define the model and the controller, without defining the view.<br> <TabAtkins> gregwhitworth: So I tried to take the whole explainer and scrunch it down here<br> <TabAtkins> gregwhitworth: [reads the slide]<br> <TabAtkins> gregwhitworth: So a quick thought exercise<br> <TabAtkins> gregwhitworth: Everyone envision a select<br> <TabAtkins> gregwhitworth: What does it look like, what are the behaviors<br> <TabAtkins> gregwhitworth: [shows W95 screenshot]<br> <TabAtkins> gregwhitworth: I wonder if anyone had this in their head<br> <TabAtkins> [shows very old Apple UI]<br> <TabAtkins> gregwhitworth: No scrollbar, but a checkbox, and some colors next to the options<br> <fantasai> s/UI/UI - Mac OS 7.0/<br> <TabAtkins> [shows a more modern filtering UI from a webpage]<br> <TabAtkins> gregwhitworth: You could imagine this being a composite control as well, being an type=search actually that just has the behavior<br> <TabAtkins> [shows a contact selector]<br> <fantasai> s/next to the options/next to the options. Actually can't even do this on Web platform today/<br> <TabAtkins> gregwhitworth: Or maybe like this, showing off select limitations today. This uses a grid to show the pictures, name, and title.<br> <TabAtkins> gregwhitworth: But utlimately it's just a select underneath everything, giving some values.<br> <TabAtkins> [shows iOS "roller" select]<br> <tantek> s/iOS/old iOS<br> <TabAtkins> gregwhitworth: Emphasize again that the model and behaviors aren't changing, but controller does a little - scroll events are scrolling this, but site might want to take over.<br> <TabAtkins> gregwhitworth: So wanted to break down the anatomy of the inputs<br> <TabAtkins> gregwhitworth: If there's standard terminology on the web already, we use that<br> <TabAtkins> [shows off a select's anatomy]<br> <TabAtkins> gregwhitworth: A particular bit of controversy here is whether the "top" part of a select is a button (as currently noted) or a textbox, given how many UI frameworks already give type-in<br> <TabAtkins> gregwhitworth: This ties into the accent color from last week, can't define it without knowing where it'll be applied<br> <TabAtkins> gregwhitworth: Then once you have the parts, you can define how events transition between parts.<br> <TabAtkins> gregwhitworth: Based on research across component libraries, figuring out if it was nailed down due to user research, or accidental, or if it needs to be stadnardized at all, etc<br> <TabAtkins> gregwhitworth: What we want overall is to obviate the need for authors to go to WAI-ARIA's big list of conditions<br> <TabAtkins> gregwhitworth: Complicated mapping of a11y conditions back to your control<br> <TabAtkins> gregwhitworth: And since so much of the issue is just "i want to make slight cosmetic tweak", but they ahve to reinvent all the rest themselves<br> <TabAtkins> gregwhitworth: We find that if you provide the core functionality, with type-ahead searching, almost nobody actually wants more functionality at that point. They just want cosmetic control.<br> <TabAtkins> gregwhitworth: Another part of the explainer is the part="" attribute, giving it meaning in the control itself.<br> <TabAtkins> gregwhitworth: So we've exposed that there are actual slots and parts in our Open UI components.<br> <TabAtkins> [shows off a custom select's HTML code]<br> <TabAtkins> gregwhitworth: Note here, on the "button" container, I want to replace that top part with my own UI, but let the rest of the control code work as normal.<br> <TabAtkins> gregwhitworth: So by noting the part="", the component just grabs that, and otherwise hooks up everything as it would with its own button.<br> <TabAtkins> gregwhitworth: So this becomes powerful - so long as the element is child of the select, the select can give it meaning and beahvior.<br> <TabAtkins> gregwhitworth: Then the controller comes along, adds in appropriate ARIA, tabindex, listeners, etc.<br> <TabAtkins> gregwhitworth: So I feel like people are often "that sounds cool in theory", but we've gone and built a WC that follows this model.<br> <TabAtkins> gregwhitworth: Not done yet.<br> <TabAtkins> [shows off control]<br> <TabAtkins> gregwhitworth: When I hit spacebar we move to the options, I can arrow and hit Enter and it selects that one.<br> <TabAtkins> gregwhitworth: Here's a Bootstrap example; the text of the select option doesn't bring up the popup, but the arrow does.<br> <tantek> great presentation gregwhitworth<br> <TabAtkins> gregwhitworth: And here's a more extreme radial design, that still works exactly per normal select interactions<br> <TabAtkins> gregwhitworth: And here's a typeahead select, giving minimal customization and hooking into the underlying search mechanics.<br> <tantek> q+ to ask about the select pop-up button vs list matching widths<br> <gsnedders> q?<br> <TabAtkins> Rossen_: I applaud you for not stopping on this journey<br> <Rossen_> ack tantek<br> <Zakim> tantek, you wanted to ask about the select pop-up button vs list matching widths<br> <TabAtkins> tantek: I tried to work on this 20 years ago, greatly sympathize, great work.<br> <TabAtkins> tantek: For select, one common thing I saw in your examples is the button and list being different widths<br> <TabAtkins> tantek: Having two things in CSS match their shrink-to-fit width is, hm, hard or impossible?<br> <TabAtkins> gregwhitworth: bc they're just block-level siblings, you can use grid to make them the same width if you want<br> <TabAtkins> gregwhitworth: This select is no longer a separate window - we can't do that without security issues.<br> <Rossen_> ack fantasai<br> <TabAtkins> fantasai: I know that select dropdowns have special beahvior when neativel implemented, to avoid falling off the edge of the screen. Does this mean if I style my select, I need to reimplement that?<br> <TabAtkins> gregwhitworth: Expect us to come with proposals for exactly that. I don't expect you to reimplement, we should make it easy to add in.<br> <tantek> that seems like a new layout / positioning feature<br> <TabAtkins> fantasai: Looks like you're lookin at how to build UI from scratch - have you looked at how to take existing markup and make it more stylable, so people dont' need to bring their own?<br> <tantek> +1 fantasai - we want to solve *both*<br> <TabAtkins> gregwhitworth: My one hesitance is, say, take checkbox. If we dont' allow replacements, but let you change color of the glyph - people quickly start asking for animation, or adding a label, etc.<br> <TabAtkins> gregwhitworth: Gets more complex really quickly.<br> <TabAtkins> fantasai: Not saying to stop there, but we shoudl go in from both sides, so we can minimize the number of people that need to rebuilt their control.<br> <TabAtkins> fantasai: While also making it possible for people rebuilding their comonetns to make it easy.<br> <TabAtkins> Rossen_: Last time, in Toronto, we decided not to use CSS to expose or define parts.<br> <tantek> q+<br> <TabAtkins> That's not a relevant address to fantasai's concern - she's not talking about defining parts in CSS.<br> <TabAtkins> tantek: Strong agree to also let people fix native markup.<br> <TabAtkins> <br dur=15min><br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5350#issuecomment-666427225 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 July 2020 14:58:53 UTC