16:58:21 RRSAgent has joined #css 16:58:21 logging to https://www.w3.org/2020/10/12-css-irc 16:58:23 RRSAgent, make logs Public 16:58:24 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:00:15 whsieh has joined #css 17:01:03 present+ 17:01:20 Guest60 has joined #css 17:01:22 present+ 17:01:24 jan has joined #css 17:01:31 present+ 17:01:32 brodymckee has joined #css 17:01:39 present+ 17:02:13 alisonmaher has joined #css 17:02:25 una has joined #css 17:02:32 present+ 17:02:33 chance_ has joined #css 17:02:47 bkardell_ has joined #css 17:02:59 present+ 17:03:03 levithomason has joined #css 17:03:13 Present+ Levi Thomason 17:03:15 present+ 17:03:16 present+ 17:03:24 present+ 17:03:27 present+ 17:03:28 present+ 17:03:29 present+ 17:03:38 present+ 17:03:39 https://github.com/WICG/open-ui/blob/master/meetings/telecon/tpac-openui-csswg-oct-2020.md 17:03:41 present+ myles 17:03:43 present+ 17:03:50 present+ 17:04:03 present+ 17:04:14 Topic: Introductions 17:04:43 Greg Whitworth, Product at Salesforce 17:04:51 Jan Miksovsky, Salesforce architect on their Base Web Components team 17:04:56 Francis_Storr has joined #css 17:04:59 Myles C. Maxfield, software engineer, Apple, Inc. 17:05:10 present+ 17:05:23 present+ 17:05:27 Chance Strickland, developer on the primitive components team at Modulz 17:05:28 Jen Simmons, Apple, Inc. 17:05:47 Francis Storr, Intel. 17:05:55 Emilio Cobos, Mozilla 17:05:56 present+ 17:06:02 Tab Atkins-Bittner, Google 17:06:03 present+ 17:06:06 Elika Etemad aka fantasai, W3C Invited Expert to the CSSWG, formerly Mozilla 17:06:16 present+ 17:06:21 Theresa (Tess) O'Connor, the standards lead for the WebKit team at Apple 17:06:25 Alan Stearns, Adobe, chair CSSWG 17:06:42 Simon Pieters, Sr. Open Web Engineer, Bocoup 17:07:47 Melanie Richards, Microsoft, PM on HTML Platform 17:08:21 Levi Thomason, Principle Software Engineer @ Microsoft architect for Fluent UI, Semantic UI React maintainer, Open UI co-chair 17:08:22 Una Kravets, Developer Advocate on Google Chrome 17:08:29 Brian Kardell, developer advocate at igalia sometime represent open jsf, participating in CSSWG and OpenUI 17:08:45 brandonferrua_ has joined #css 17:08:52 *also involved in OpenUI 17:09:03 James Craig, Accessibility Standards, Apple 17:09:05 boazsender has joined #css 17:09:23 present + Boaz Sender, Bocoup 17:09:54 present+ 17:10:21 Alison Maher, Microsoft layout team 17:11:22 Topic: Font Picker Control 17:11:32 myles: Font pickers have some benefits we're interested in pursuing 17:11:43 myles: Don't want to expose fonts installed on the system as a list 17:11:53 myles: bad for privacy because of fingerprnting 17:11:59 myles: ... 17:12:26 myles: font-picker could punch through and allow the page to access fonts installed on the system beyond the basic set 17:12:35 myles: No proposal or plan yet, but want to work on this particular project 17:12:36 q+ 17:12:40 myles: and think Open UI is a good place to do that 17:12:43 jamesn has joined #css 17:13:17 present+ 17:13:26 present+ 17:13:41 TabAtkins: Myles, you aware of the font picker proposal I put together? 17:13:43 myles: nope 17:13:48 TabAtkins: I'll send you a link 17:14:02 https://github.com/tabatkins/proposal-local-font-access 17:14:03 ack TabAtkins 17:14:19 present+ 17:14:20 Topic: Meeting Introduction 17:14:34 gregwhitworth: Meeting called because CSSWG diving into form control issues 17:14:42 gregwhitworth: Open UI has been digging into this also 17:14:54 gregwhitworth: Melanie and I, while discussing these topics, running into meta topics not just tech itself 17:15:01 tantek has joined #css 17:15:04 gregwhitworth: Wanted to take a step back and come up with a holistic proposal 17:15:08 present+ 17:15:23 gregwhitworth: so first want to go through the entire presentation to get a view on the forest, not get stuck on individual trees 17:15:34 gregwhitworth: Interested in feedback 17:16:06 gregwhitworth: Please save questions for the discussion at the end. 17:16:10 Topic: Presentation 17:16:18 gregwhitworth: I work at Salesforce on the ?? in particular 17:16:28 gregwhitworth: formerly on EdgeHTML, working on form controls with the team there 17:16:57 melanierichards: I work at MSFT. doing multiple things as a CM on HTML platform. One is how can we make more customizable control UI for Web Platform 17:17:12 melanierichards: Before we get into any solutions, wanted to spend time to define the problem. 17:17:29 melanierichards: [ projects forced colors mode calendar / color pickers ] 17:17:54 melanierichards: A lot of work between Google and MSFT to update form controls for modern aesthetic, and also integrate well with different assistive technologies. 17:18:03 Kaelig has joined #css 17:18:05 melanierichards: Here's an example of controls working in Windows High Contrast mode 17:18:26 melanierichards: Problem is that for all of the care and though put in by each implementer into native control, a lot of developers are not using them for various reasons. 17:18:40 melanierichards: Will talk about 17:50:16 https://1drv.ms/p/s!AhG1j1eK4stagbq2fYytKAA1kCU7icM 17:50:44 gregwhitworth: To make it fully styleable have to standardize the parts 17:50:58 gregwhitworth: The only thing I'm opting in here, I want to be able to have a set of parts and anatomy that are the same across UAs 17:51:10 gregwhitworth: by adding this in, I can say "apply the standard DOM and base styles" 17:51:14 gregwhitworth: Now replaced those parts 17:51:24 gregwhitworth: leverages modifications to parts 17:51:34 gregwhitworth: Ultimately, end up with a standardized anatomy 17:51:41 gregwhitworth: Need to make sure w have all the right parts 17:51:56 gregwhitworth: but once we have that base set of styles, when that is opted into, you get something which looks very basic 17:52:02 gregwhitworth: and there's a structure that's agreed upon 17:52:07 gregwhitworth: that you can build on 17:52:10 fantasai, you might want to mute your mic. 17:52:25 gregwhitworth: Imagine within a base style sheet that's standardized, could look like this 17:52:33 gregwhitworth: achieves similar appearnace 17:52:52 gregwhitworth: Not ground-breaking, building on appearance 17:53:08 gregwhitworth: What's missing is a base set of styles 17:53:19 gregwhitworth: that the author can start with and build on 17:53:51 melanierichards: Old friend the MVC model 17:54:00 melanierichards: Talking about extensibility 17:54:09 melanierichards: today primarily talking about extending the view 17:54:27 melanierichards: Also would want flexibility over controller code to change behaviors, but that's separate discussion 17:54:35 melanierichards: Several ways to do this in our proposed solution 17:54:43 melanierichards: Unlock styling of select, e.g. 17:55:02 melanierichards: imagine select is buton part with a .. inside it, and options inside of that 17:55:12 melanierichards: author could replace one part of the control with slot technology 17:55:21 melanierichards: they can then provide richer markup within that listbox 17:55:33 melanierichards: so here in this listbox, each option has an image, the person's name, their title, their online status 17:55:44 melanierichards: whichever part not replaced, gets default for that type of control 17:56:01 melanierichards: other option is, I just want to replace the shadow DOM of the control with my own structure 17:56:10 melanierichards: Web developer can use their own 17:56:19 melanierichards: what's critical about this, if you're going to do full replacement of the view 17:56:32 melanierichards: the part sof the shadow DOM must be labelled with 'part' , and must have all the requisite parts 17:56:44 melanierichards: Controller needs to know which parts it's expecting, so can wire things up based on that. 17:56:58 melanierichards: With either of these two solutions, we expect controller control to provide a lot for the web developer 17:57:10 melanierichards: Would still provide ... and acessibility semantics 17:57:26 melanierichards: Can also wire up correct behaviors, like keyboard interactions for opening/closing the pop-up and selecting options 17:57:36 melanierichards: those would all be provided by the platform, rather than something the author has to provide 17:57:44 melanierichards: In order to do all of this, we require some standardization 17:57:51 melanierichards: So standardization of anatomy of control 17:58:07 melanierichards: in order to replace slots predictably, need to know what parts are provided, how are they nested, how do they relate to each other 17:58:14 melanierichards: All of the screenshots here are from Open UI research 17:58:23 melanierichards: We also have to define the states the conrol can be in 17:58:32 melanierichards: Also need to standardize required behaviors 17:58:35 drousso has joined #css 17:58:37 melanierichards: How does the control transition from state to state? 17:59:07 melanierichards: How does keyboard interaction work? Type-ahead? These all need to be defined so that they can be provided predictably from browser to browser and context to context. 17:59:21 melanierichards: Question: what process do we need for holistic control standardization? 17:59:32 gregwhitworth: We want to have this approach every time we talk about a control 17:59:39 gregwhitworth: whenever someone wants to add a control 17:59:54 gregwhitworth: want to do a thought experiment to make sure we're doing the best design of the conrol 18:00:06 gregwhitworth: and wrt full extensibility, need to define the behaviors 18:00:18 gregwhitworth: if we don't define the behaviors, then author can't know what to extend and hook into 18:00:26 gregwhitworth: Controls are ultmately a composite of everything 18:00:37 gregwhitworth: All of these companies, everyone building a control or component, you start with a design 18:00:43 gregwhitworth: and ultimately what ends up happening is 18:00:59 gregwhitworth: they go and look at the existing specs, HTML/DOM/ARIA/CSS/ etc. 18:01:10 gregwhitworth: they crowd-source 18:01:14 gregwhitworth: Ultimately produce a blueprint 18:01:32 gregwhitworth: Quite a few have user research, e.g. on a touch deveice, this is what's the best from user research 18:01:45 gregwhitworth: Maybe very insightful bug filed, but not shared outside their tracker 18:02:01 gregwhitworth: We want a holistic approach to defining these components, one place to define the blueprints 18:02:05 gregwhitworth: for the entire web platform 18:02:12 gregwhitworth: The composite standardization of the control 18:02:35 gregwhitworth: not just the element and its sub-element,s not just the model that's attached to that, but also behaviors and accessibility, etc. is what makes a select a select 18:02:42 gregwhitworth: want to have these all defined within open UI 18:02:54 gregwhitworth: We might not end up moving some of these into the Web platform 18:03:02 gregwhitworth: Example, skeleton component. 18:03:10 gregwhitworth: not enough consistency of anatomy to put into HTML 18:03:20 gregwhitworth: but common terminology used 18:03:33 gregwhitworth: went to ARIA and asked a new model, came back with use existing stuff this way 18:03:39 gregwhitworth: Anyone can come and implement against this 18:03:51 gregwhitworth: So basicaly process I'm putting forth, when new pseudo-elements come in for file or range, 18:03:59 gregwhitworth: take to Open UI to define what that looks likes 18:04:15 gregwhitworth: if CSS needs a pseudo-element, then that gets defined in CSS pseudo spec, along with other primitives 18:04:32 gregwhitworth: ultimately, that's the procedural discussion I'd like to have 18:04:39 gregwhitworth: That's the end of the deck. 18:04:58 gregwhitworth: Now want to come back and talk about each tree :) 18:05:15 gregwhitworth: So want to take a 15min break? 18:05:30 gregwhitworth: next topic, we'll be discussing the problem 18:05:42 gregwhitworth: might be pedantic, but want to resolve that it's a problem 18:05:51
18:06:03 s/15/15min/ 18:06:30 Yup, having slide context with the convo is useful. 18:07:03 gregwhitworth: that slide link didn't work for me 18:08:17 s/Limited -/Limited - styleable elements and pseudo-elements, but limited in some way/ 18:08:36 boazsender: it works for me in Edge and Firefox on the Mac 18:08:48 s/xxx -/Fully Styleable - Developers can opt into standardized parts and structure and base styles that are fully restyleable/ 18:09:24 s/Xxxxx -/Fully Extensible - standardization of a control's anatomy, states, behaviors, allowing re-using controller code via defined parts/ 18:15:50 Youtube video is here: https://youtu.be/2S2nSqh6EUw 18:16:52 akeerthi has joined #css 18:18:45 Slides are now archived at https://lists.w3.org/Archives/Public/www-archive/2020Oct/att-0002/OpenUI-control-model-definition.pdf 18:20:14 Topic: Problem Discussion 18:20:39 i/Topic: Introductions/ScribeNick: fantasai/ 18:20:39 present+ 18:20:42 ScribeNick: TabAtkins 18:20:50 I have made the request to generate https://www.w3.org/2020/10/12-css-minutes.html fantasai 18:20:53 I have made the request to generate https://www.w3.org/2020/10/12-css-minutes.html fantasai 18:21:14 gregwhitworth: the proposed resolution I'm getting toward is "webdevs recreating form controls is a problem" 18:21:22 gregwhitworth: may seem pedantic, but it's our first goal 18:21:50 astearns: I don't thin kit's a problem for webdevs to make their own controls. We shouldn't *keep* them from doing it. 18:22:07 astearns: But since so many do end up spending so much effort on it, i see the problem as "let's make it easier, so they dont' have to" 18:22:09 q+ 18:22:17 fantasai: It's a problem they feel the need to, in so many cases 18:22:23 q+ 18:22:27 q+ 18:22:38 levithomason: The problem is that they're all creating the same thing that already exists. 18:22:48 ack nicole 18:23:06 nicole: in my previous incarnation i spent 5 years with a business i founded to fix people's broken front-ends 18:23:12 q+ 18:23:22 s/exists/exists. If they were creating something specific that didn't exist, that would be OK/ 18:23:25 nicole: each place i would consult with, i would think "oh god, i won't know what i'm doing here, they're gonna do such different things" 18:23:32 q+ 18:23:41 nicole: But actually almost all the code i had to write was the same for everyone 18:23:53 nicole: A thin layer of different branding, but ovrall the same set of components 18:24:02 nicole: So for me it seems like a *really clear* cowpath to pave 18:24:13 ack jensimmons 18:24:30 jensimmons: authors creating their own form controls from scratch, ignoring html, being stuck only with JS as their tool, is a problem 18:24:41 q+ to address the claim that this is a convenience feature "not a problem" due to the ability of authors to make custom controls. Accessibility... 18:24:51 jensimmons: especially for users, for a11y, because it's really not possible to test on every browser, every device, this is really something html *should* be doing 18:25:03 jensimmons: I dont' think it's a problem tha tauthors have something powerful letting them do this 18:25:12 q+ 18:25:19 jensimmons: a lego kit letting them hook into this all is complex, but it's more semantic 18:25:36 ack una 18:25:37 jensimmons: so i don't think it's a problem that they can do somethign complex, i think it's a problem that they're using something bad for users 18:25:42 I have made the request to generate https://www.w3.org/2020/10/12-css-minutes.html fantasai 18:25:58 una: Problem here is not giving devs the tools they need to buid what they want. a11y issues, everyone recreating the same form elements 18:26:04 una: Like Nicole said 18:26:15 msumner has joined #css 18:26:20 una: We've heard and seen time and time again, that users need these browser features, and devs aren't giving them 18:26:37 jjenzz has joined #css 18:26:51 ack me 18:26:51 jcraig, you wanted to address the claim that this is a convenience feature "not a problem" due to the ability of authors to make custom controls. Accessibility... 18:26:52 una: In the work that OpenUI has done, we've looked at these cowpaths/templates and how they've been used, and that can bring us in a direction, but really the problem is folks don't have the primitives they need to build the forms they want 18:27:16 jcraig: Jen state dmost of what I wanted, and Una. The primitives are lacking. 18:27:37 jcraig: ONe thing to add, the problem is that with the exception fo a few simple controls - clickables like radios - I've *never* seen controls done in a way that includes all the a11y. 18:28:02 jcraig: even a11y-conscious devs fall short of support that the platform provides in their builtins. So it's not even just a convenience issue, it's a real problem. 18:28:06 ack jan 18:28:11 q+ 18:28:19 zakim, close queue 18:28:19 ok, astearns, the speaker queue is closed 18:28:22 +1 to jcraig a11y comment 18:28:26 s/seen controls /seen *custom* controls / 18:28:28 jan: I agree it's a problem, but I think more in economics - if you consider a control, today controls are fairly monolithic 18:28:44 jan: A select might have, say, 40 different things it's trying to do - layout, styling, presentation, behavior 18:29:06 jan: If someone is trying to create a special control, they're generally trying to change some subset of that - they're fine with 37 of the things it's doing, want to repalce 3 of them 18:29:24 boazsender has joined #css 18:29:44 jan: But the cost to replace a custom select is not proportional. They have to replace *all* of them. Wanting to change 3 aspect you'd think would be less than changing 10 of them, but there's actually no relationship, they all cost the same (lots). 18:29:44 s/clickables like radios/clickables/toggleables like radios, checkboxes, buttons/ 18:30:00 jan: So I dont' think of recreating the entire thing 18:30:02 s/repalce/replace/ 18:30:16 jan: Devs need a way to do this alteration in a proportionate-cost way 18:30:31 ack Kaelig_ 18:30:32 rrsagent, make minutes 18:30:32 I have made the request to generate https://www.w3.org/2020/10/12-css-minutes.html jcraig 18:30:39 Kaelig_: Agree with a lot of this, and the way the problem is written now. 18:30:54 +1 to Jan — or, to thinking about the economics. Without the tools web teams need built into the browser, only the biggest budget projects can afford to solve these kinds of needs. 18:30:54 Kaelig_: The platform doesn't allow peole to do the right thing. 18:31:05 Kaelig_: Even if you're a11y-minded, you're gonna break a11y somehow, somewhere 18:31:17 Kaelig_: Enabling the interaction model to be reused, would be fantastic 18:31:29 ack miriam 18:31:34 miriam: I'm currently living Nicole's 5y-ago experience 18:31:36 you can't have to throw away all of the wonderful platform magic to tweak one little thing which just isn't sweet enough - the more we get away from that being the a general problem the better off we are 18:31:42 miriam: There's different layers of needing to rebuild. 18:31:56 miriam: There are times I need the full extensibiility, but often I need various steps in between 18:32:18 miriam: So important to me as a dev is being able to adjust only waht I need to adjust, not having a control that is either "no styling" vs "rebuild everything" 18:32:33 q+ 18:33:14 q+ 18:33:19 TabAtkins: ... 18:33:33 TabAtkins: It's really important to understand how far browsers relying on OS-level controls are willing to go 18:33:51 gregwhitworth: We literally get to that in a sec 18:33:52 TabAtkins: If we make problems that are only solveable by custom controls, can only solve problems solveable by Chrome today 18:33:59 q+ 18:34:05 gregwhitworth: We'll get to that. i just want to agree that there's a problem. 18:34:28 jan: Wanna confirm there's a problem here, like acknowledging it. 18:34:35 jan: is the question about *this formulation* of the problem? 18:34:46 RRSAgent, create minutes 18:34:46 I have made the request to generate https://www.w3.org/2020/10/12-css-minutes.html gsnedders 18:34:59 gregwhitworth: This ordering is on purpose, want to agree on the problem first then talk about solutions 18:35:04 I'm logging. I don't understand 'make make minutes v2', fantasai. Try /msg RRSAgent help 18:35:18 I have made the request to generate https://www.w3.org/2020/10/12-css-minutes.html fantasai 18:35:35 gregwhitworth: So can we minute that nobody thinks we *shouldn't* address this problem? 18:35:47 I also agree this is a problem I would like to solve. 18:36:00 fantasai: Take greg's resolution as in his slide? 18:36:15 astearns: I think Jan was saying that's not *all* we need 18:36:18 jpennig has joined #css 18:36:24 gregwhitworth: Right, but I want to address the additional parts ina bit 18:36:39 proposed resolution: Web developers needing to re-create a browser's form controls is a problem. 18:36:48 RESOLVED: Web developers needing to re-create a browser's form controls is a problem. 18:36:49 zakim, open queue 18:36:49 ok, astearns, the speaker queue is open 18:36:53 gregwhitworth: Definition of a control 18:36:59 gregwhitworth: taken from openui 18:37:06 gregwhitworth: No normative dfn 18:37:17 q+ 18:37:30 [on slide] A control is a type of component that manages user interaction. The control has controller code that maanages changes in teh component's state and its model based on user interactionw ith its parts. 18:37:33 ack hober 18:37:42 q+ 18:37:45 hober: The high-level dfn seems fine. 18:37:51 q+ 18:37:57 hober: The word "component" has a lot of v specific meanings on the web 18:38:09 hober: Might be good to avoid using this word to avoid confusiong 18:38:19 gregwhitworth: Would it be worth defining a component? 18:38:32 suggestion for the name: widget 18:38:33 Agree with hober, btw, "component" is an overloaded word already 18:38:39 widget is used in html and aria 18:39:04 nicole: I dont' think "widget" speaks to what we're discussing here. People are usually using that to mean something self-contained; it controls itself, and doesn't interact with the outside page. 18:39:11 q+ 18:39:15 nicole: Like twitter widget, or commenting widget. 18:39:16 q- 18:39:23 A control is an *element* that manages user interaction? 18:39:32 Agree with Nicole on "widget" definition not suitable to this case 18:39:33 +1, element seems sufficient 18:39:43 nicole: I think generally speaking, people use "component" and "control" interoperably 18:39:44 "Element" is what came to mind for me at first, but I'm not sure its better than component 18:39:51 element is smart 18:40:04 (I think element is a smart substitute) 18:40:10 astearns: Suggestion from IRC is "element" 18:40:17 nicole: Doesn't that usually indicate a singular element? 18:40:25 fantasai: Can we just add a note to bikeshed the term later? 18:40:25 ack levithomason 18:40:39 levithomason: Greg, on this dfn, does this exclude button? 18:40:47 gregwhitworth: No, I'd expect this to include a button 18:41:01 from a thesaurus: part, element, ingredient, constituent, fundamental, unit, factor 18:41:03 gregwhitworth: A button takes in user interaction. 18:41:24 Just making it clear: the problem here is the conflict with "web component" 18:41:38 Which is already an existing concept that means something specific. 18:41:55 perhaps a 'design component' then? 18:41:57 gregwhitworth: So a button is a control 18:42:10 q- 18:42:26 levithomason: So does that mean a component doesn't necessarily manage the state? Unless CSS pseudoclasses count as stateful. 18:42:31 q+ 18:42:54 ack bkardell_ 18:42:55 gregwhitworth: I think that's getting a bit too specific - responding to the disable state (and not clicking) is responding to user input and component state, right? 18:43:09 are progress and meter elements "controls" as well? these aren't user interactible 18:43:12 bkardell_: Based on tess and nicole, ARIA and html use "widget" for this. 18:43:26 gregwhitworth: Do we want to bikeshed the component, but take as given that the general meaning is correct? 18:43:49 hober: The first line of this, "component" is the load-bearing term. 18:43:53 q+ 18:44:06 q+ 18:44:09 hober: Hard to take a resolution on it and just say to change the term later, if that word does all the work 18:44:15 q+ 18:44:19 astearns: Can we just remove the word? "A control manages user interaction" 18:44:47 levithomason: Was gonna similarly suggest we remove the top entirely; the second paragraph says all the same stuff, in more detail. 18:45:01 gregwhitworth: The lower says "component" too tho? 18:45:02 While it seems hard to agree on the definition without a word, I hope it’s possible to reach consensus on whether the aspects/definitions are unique and helpful. 18:45:05 I do think there's a danger with this definition that all elements are controls since states like hover and active represent user interactions that change the state of the element - presumably via controller code. 18:45:18 ack levithomason 18:45:18 a control manages user interaction, including changes in states and data 18:45:30 levithomason: The bottom defines "component" in terms of what it's doing and interacting; the top is just saying "control is a type of component", making the implicit dfn of component more important 18:45:32 BoCupp: can you speak up? 18:45:52 boazsender: I put some text in IRC suggesting we remove/clarify some detail 18:46:00 ack cbiesinger 18:46:04 ack boazsender 18:46:08 I like Boaz's definition 18:46:08 q+ 18:46:11 cbiesinger: I think we should reuse ARIA's dfn, would be helpful to use the same terms to hook into a11y 18:46:18 hober: Consistency with ARIA sounds good 18:46:18 q+ 18:46:19 q+ 18:46:40 ack una 18:46:43 q+ 18:47:06 una: A "widget" being a self-encompassed app, that's how I think of the word. A more loaded term than "component". Element->component->widget goes from "least self-enclosed" to "most self-enclosed" 18:47:14 q+ 18:47:18 una: Think removing the term entirely makes it too broad 18:47:23 ack Francis_Storr 18:47:29 Francis_Storr: WCAG uses "component" and has a dfn for this 18:47:32 Francis_Storr: Linked it 18:47:34 w3.org/TR/WCAG21/#dfn-user-interface-components 18:47:39 ARIA widget definition - Widget 18:47:39 Discrete user interface object with which the user can interact. Widgets range from simple objects that have one value or operation (e.g., check boxes and menu items), to complex objects that contain many managed sub-objects (e.g., trees and grids). 18:47:40 ack nicole 18:47:42 Proposal: A control is a thing that manages user interaction. The control has controller code that manages changes in its state and its model based on user interaction with its parts. 18:47:53 nicole: I wanted to speak to matching ARIA dfns 18:47:58 Above based on feedback so far. 18:48:18 nicole: I've seen webdevs struggling to understand ARIA even when they really care, and so ideally it shouldn't be directly exposed to end developers 18:48:44 +1 to what nicole said - that's why I said just to add to the complexity - I just intend to point out that these terms are overloaded in complex ways today that mean different things to different audiences! 18:49:04 nicole: When i fix people's front-ends, i think i've heard *one* client ask for everything to be accessible. we should make sure the end result is accessible, but i'm wary to think of ARIA as having th epatterns. Instead, the patterns live in design systems, so we should look more to that for naming 18:49:23 ack msumner 18:49:33 +1 to UI components 18:49:36 Agree fully on following design systems. These are the things that define the web. 18:49:44 melanierichards: Suggest "UI components". Work with a few frameworks, and we use that terminology already. I'm in ARIA WG and don't like using "widgets" either 18:49:48 ack jensimmons 18:49:52 +1 to Nicole's suggestion to follow the terminology from design systems, not basing them on ARIA controls or patterns 18:50:09 jensimmons: In the context of design system, "component" has a meaning, "web components" has a meaning. Important to put some time into. 18:50:16 jensimmons: But this isn't the right place to put time into it. 18:50:30 +1 I liked melanierichards suggestion of "UI component" 18:50:31 Updated proposal: A control is a UI component that manages user interaction. The control has controller code that manages changes in its state and its model based on user interaction with its parts. 18:50:37 Agree on moving on. 18:50:59 astearns: I'm seeing enthusiasm for "UI component". Could resolve to take that for now, and open a bikeshedding issue. 18:51:01 +1 to follow the terms from design systems, and also, let's incorporate the great work aria is doing with the practice guidelines design patterns: https://w3c.github.io/aria-practices/examples/ 18:51:02 s/melanierichards/msumner 18:51:13 una: I think "UI component" helps identify what type it is, and adds to specificity of our exact topic 18:51:15 (for UI component) 18:51:42 hober: Going back to Jen's comment, we should have this convo elsewhere, it might take longer than we have here. 18:51:45 I can re-open this one: https://github.com/WICG/open-ui/issues/81 18:52:07 hober: What part of resolving on this definition is required for the rest of the convo? 18:52:08 +1 gregwhitworth I can post my suggestion there 18:52:11 q+ 18:52:14 gregwhitworth: Don't think it's needed yet. 18:52:24