Meeting minutes
<zcorpan_> https://github.com/WICG/open-ui/blob/master/meetings/telecon/tpac-openui-csswg-oct-2020.md
Introductions
<gregwhitworth> Greg Whitworth, Product at Salesforce
<jan> Jan Miksovsky, Salesforce architect on their Base Web Components team
<myles> Myles C. Maxfield, software engineer, Apple, Inc.
<chance_> Chance Strickland, developer on the primitive components team at Modulz
<jensimmons> Jen Simmons, Apple, Inc.
<Francis_Storr> Francis Storr, Intel.
<emilio> Emilio Cobos, Mozilla
<TabAtkins> Tab Atkins-Bittner, Google
Elika Etemad aka fantasai, W3C Invited Expert to the CSSWG, formerly Mozilla
<hober> Theresa (Tess) O'Connor, the standards lead for the WebKit team at Apple
Alan Stearns, Adobe, chair CSSWG
<zcorpan_> Simon Pieters, Sr. Open Web Engineer, Bocoup
<melanierichards> Melanie Richards, Microsoft, PM on HTML Platform
<levithomason> Levi Thomason, Principle Software Engineer @ Microsoft architect for Fluent UI, Semantic UI React maintainer, Open UI co-chair
<una> Una Kravets, Developer Advocate on Google Chrome
<bkardell_> Brian Kardell, developer advocate at igalia sometime represent open jsf, participating in CSSWG and OpenUI
<una> *also involved in OpenUI
<jcraig> James Craig, Accessibility Standards, Apple
<alisonmaher> Alison Maher, Microsoft layout team
Font Picker Control
myles: Font pickers have some benefits we're interested in pursuing
myles: Don't want to expose fonts installed on the system as a list
myles: bad for privacy because of fingerprnting
myles: ...
myles: font-picker could punch through and allow the page to access fonts installed on the system beyond the basic set
myles: No proposal or plan yet, but want to work on this particular project
myles: and think Open UI is a good place to do that
TabAtkins: Myles, you aware of the font picker proposal I put together?
myles: nope
TabAtkins: I'll send you a link
<TabAtkins> https://github.com/tabatkins/proposal-local-font-access
Meeting Introduction
gregwhitworth: Meeting called because CSSWG diving into form control issues
gregwhitworth: Open UI has been digging into this also
gregwhitworth: Melanie and I, while discussing these topics, running into meta topics not just tech itself
gregwhitworth: Wanted to take a step back and come up with a holistic proposal
gregwhitworth: so first want to go through the entire presentation to get a view on the forest, not get stuck on individual trees
gregwhitworth: Interested in feedback
gregwhitworth: Please save questions for the discussion at the end.
Presentation
gregwhitworth: I work at Salesforce on the ?? in particular
gregwhitworth: formerly on EdgeHTML, working on form controls with the team there
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
melanierichards: Before we get into any solutions, wanted to spend time to define the problem.
melanierichards: [ projects forced colors mode calendar / color pickers ]
melanierichards: A lot of work between Google and MSFT to update form controls for modern aesthetic, and also integrate well with different assistive technologies.
melanierichards: Here's an example of controls working in Windows High Contrast mode
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.
melanierichards: Will talk about <select>, special pain point for devs
melanierichards: Here's several examples of select drop-downs built from scratch by devs
melanierichards: The fumdanmental form of the select isn't change, no behavioral difference, but desire for slight changes in styling:
melanierichards: changing the drop-down button glyph, controlling colors exactly, etc.
melanierichards: Another example is from Delta, where you need to pick two dates spanning potentially multiple months, cannot be achieved with native calendar controls.
melanierichards: Needing to recreate controls in order to match the branding and cross-platform
melanierichards: is common understanding, is it real?
melanierichards: we ran a survey, and yes devs are recreating form controls
melanierichards: 36.6% just wanted to adjust the appearahce
melanierichards: Another 31.6% wanted to add functionality
melanierichards: Third major reason, 27.3%, to recreate is browser non-interop
melanierichards: When we observe what are the top 10 controls recreated by web devs
melanierichards: select, checkbox are the top, date close behind, radio, then file, progress ...
melanierichards: This isn't just this one survey pointing to this problem.
melanierichards: we talked to top companies, and they would prefer not to recreate the controls
melanierichards: can we make this better, can we increase the use of native controls?
melanierichards: People are recreating these, it's a fact.
melanierichards: but also true that it's causing a lot of pain
melanierichards: 42.7% of devs consider select to be the most frustrating
melanierichards: date is next, 17%
melanierichards: others lower
melanierichards: MDN Web DNA survey also lists this as a problem
melanierichards: 26.7% frustrated at inability to customize components
melanierichards: 20% wrt missing components
<una> @tantek there is a recording to be shared later
<tantek> thanks una!
melanierichards: whatever we do to solve this, need to get brand cohesion and behavioral cohesion
melanierichards: [ shares some complaints about styling native form controls ]
melanierichards: Wanted to get a sense of how much opportunity do we have to solve this problem with customizable controls
melanierichards: Ran opportunity analysis
melanierichards: 2 buckets of folks: research folks recruited people in design/front-end/fullstack and then also reached out on Twitter
melanierichards: Want to figure out is how important is something for a user, in our case web developers
melanierichards: and how paintful is it today, how satisfied are with it?
melanierichards: question is, how much impact could we have by solving this problem?
melanierichards: [ share some sample questions ]
melanierichards: We found that there was opportunity across the board
melanierichards: anything scoring 10 and above represents a strong opportunity, and on appearance, frequency, effort, and interop all above 10
melanierichards: ability to change appearance of control is important, and it's a frequent problem
melanierichards: it's a very effortful problem, having to build up your own control
melanierichards: interop is a high concern, making customizations interoperable is super critical
melanierichards: we've touched on the fact that recreating controls is paintful for developer, but also for user
melanierichards: "Are you testing for accessibility on your controls?" 31.2% said no
melanierichards: no response from 48%
melanierichards: we surmise many of those are nos
melanierichards: this is very unfortunate
melanierichards: When I joined the workforce, we hadn't talked about accessibility in my program
melanierichards: have to pull in knowledge from other people, ad-hoc, while being charged with building components that have a consisten brand and work well everywhere.
melanierichards: when recreating controls, putting onus on devs to get it right
melanierichards: and issue around ppl not having the right expertise
melanierichards: better to build on top of the platform and get these benefits for free
melanierichards: So we wanted to find out, how does this lack of a11y testing bear out in the real world
melanierichards: and we find a lot of problems
melanierichards: and even when it works, users get an inconsistent experience
melanierichards: e.g. for a drop-down, keyboard controls differ from site to site
melanierichards: One keyboard user has to relearn how to use the control from site to site
melanierichards: because all been built from the ground up
melanierichards: If make it more customizable, can UA apply consistent behavior
melanierichards: Testing is also inconsistent across browsers: some browsers get heavy testing, others not so much
melanierichards: so probably some issues introduced from lack of testing
melanierichards: Problem space is that ppl recreating these controls quite frequently
melanierichards: causes pain for devs
melanierichards: causes pain for users
melanierichards: Next, defining what is a control
gregwhitworth: We've been talking about this for 1.5yr
gregwhitworth: How can we help solve?
gregwhitworth: It's a lot of money being spent to build controls
gregwhitworth: So outlining potential proposals and solutions
gregwhitworth: and also understand what is a control
gregwhitworth: If you go looking for a definition of a control
gregwhitworth: If you want to introduce a new control to Web platform, this is what you need to define
gregwhitworth: to have a well-defined and usable control
gregwhitworth: doesn't exist
gregwhitworth: So what we found was all the properties hangning off the element represent the control
gregwhitworth: ...
gregwhitworth: [ gives abstract model of a select ]
gregwhitworth: I have a state of Open, translate that to controller code
gregwhitworth: Controller codeis the intermediary between the view and the model
gregwhitworth: We started to pull apart all the HTML controls
gregwhitworth: In some cases spec is very specific about the model, but nothing about the view
gregwhitworth: Other areas where we help with view, but not the model or the controller
gregwhitworth: So talking about controls, "A control is a type of component that manges user interaction"
gregwhitworth: ...
gregwhitworth: Spectrum of customization that's wanted by authors
gregwhitworth: This capability already exists, but longer spectrum
gregwhitworth: so we put different controls and how customizable they are
gregwhitworth: None, Hint, Limited, Fully Sytelable, Fully Extensible
gregwhitworth: ...
gregwhitworth: Is adding a few pseudo-elements enough to solve this?
gregwhitworth: We need to solve the devs' pain points so that devs use the controls
gregwhitworth: So these are the buckets we've identified
gregwhitworth: None represents exactly what it means: no control, UA full contorl
gregwhitworth: Useful enough for some devs
gregwhitworth: Then customization via hints
gregwhitworth: accent-color is an example
gregwhitworth: hint to the browser, here's a color I would like you to use, pls use it
gregwhitworth: Not necessarily bad to go after, but will only solve some amount of problems
gregwhitworth: Limited styling gets us to where CSS often lives, in pseudo-element world. Most are prefixed atm.
gregwhitworth: Let's say we didn't want to go too far, and just made pseudo-elements for all the parts
gregwhitworth: let's make it so that in certain scenarios and certain form factors, we end up always having some type of button with an arrow on selects, so going to define this part
gregwhitworth: how to define?
gregwhitworth: could make a pseudo-element
gregwhitworth: make it easy to change the color
gregwhitworth: that means have to define everything precisely
gregwhitworth: now can change the color because we defined it as SVG, but then ppl want to change the glyph, what do we do then?
gregwhitworth: Similar to password field investigation, quickly run into limitations
gregwhitworth: OK, deifne it as an image asset. But now it's hard to change the color
gregwhitworth: Interop here is limited. Ultimately pseudo-elements can only go so far
gregwhitworth: Why can't we do this today? Parts are not standardized.
gregwhitworth: Need to do the work of defining what properties are valid on the various parts
gregwhitworth: Limitations, but also do unlock use cases.
gregwhitworth: Fully styleable
gregwhitworth: this example is super simple looking, but impossible
gregwhitworth: [shows slide where selcted option is magnified by being bolded and has overlapping box size and drop-down shadow]
gregwhitworth: The listbox itself doesn't allow overflow. there's no layout capabilities on option elements at all
gregwhitworth: I'm also breaking outside the listbox's border edge
gregwhitworth: Devs have browser of choice they're testing in, so probably not testing in yours.
gregwhitworth: what ends up being implication, many ways to stack list boxes on top of each other
gregwhitworth: could use tables, flex, grid, block to do this layout
gregwhitworth: to make this easy for a Web developer to achieve
gregwhitworth: need to standardize how it's laid out
gregwhitworth: If I try to e.g. make the items lay out in a row, use 'flex-flow', works in one browser, but not in others
gregwhitworth: to make this kind of customization, need to standardize parts, DOM structure, and styling
gregwhitworth: One step further, fully styleable.
gregwhitworth: [shows a select multiple implemented with tags in the main input area, and drop-down each item has avatar, name, and title ]
gregwhitworth: Common example
gregwhitworth: Need to define the parts and states, and then can build up the accessibility model from there.
gregwhitworth: Shouldn't need to scour the web to make the control accessible
gregwhitworth: build the correct control
gregwhitworth: interoperability needed here is very high
gregwhitworth: So we have these definitions of the various buckets
[ Spectrum of Customizability slide]
gregwhitworth: what are you bringing and which bucket does it fall into?
None - no styleability or extensiblity
Hint - author provides value tha tUA applies in sprit of the property
Limited - styleable elements and pseudo-elements, but limited in some way
xxx -
XxFully Styleable - Developers can opt into standardized parts and structure and base styles that are fully restyleable
gregwhitworth: So how do we get over from None to where we want to be?
gregwhitworth: ...
gregwhitworth: How do we remove the limitations?
gregwhitworth: Let's suppose author writes this code
<select><option></option></select>
<gregwhitworth> https://1drv.ms/p/s!AhG1j1eK4stagbq2fYytKAA1kCU7icM
gregwhitworth: To make it fully styleable have to standardize the parts
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
gregwhitworth: by adding this in, I can say "apply the standard DOM and base styles"
gregwhitworth: Now replaced those parts
gregwhitworth: leverages modifications to parts
gregwhitworth: Ultimately, end up with a standardized anatomy
gregwhitworth: Need to make sure w have all the right parts
gregwhitworth: but once we have that base set of styles, when that is opted into, you get something which looks very basic
gregwhitworth: and there's a structure that's agreed upon
gregwhitworth: that you can build on
<masonfreed> fantasai, you might want to mute your mic.
gregwhitworth: Imagine within a base style sheet that's standardized, could look like this
gregwhitworth: achieves similar appearnace
gregwhitworth: Not ground-breaking, building on appearance
gregwhitworth: What's missing is a base set of styles
gregwhitworth: that the author can start with and build on
melanierichards: Old friend the MVC model
melanierichards: Talking about extensibility
melanierichards: today primarily talking about extending the view
melanierichards: Also would want flexibility over controller code to change behaviors, but that's separate discussion
melanierichards: Several ways to do this in our proposed solution
melanierichards: Unlock styling of select, e.g.
melanierichards: imagine select is buton part with a .. inside it, and options inside of that
melanierichards: author could replace one part of the control with slot technology
melanierichards: they can then provide richer markup within that listbox
melanierichards: so here in this listbox, each option has an image, the person's name, their title, their online status
melanierichards: whichever part not replaced, gets default for that type of control
melanierichards: other option is, I just want to replace the shadow DOM of the control with my own structure
melanierichards: Web developer can use their own
melanierichards: what's critical about this, if you're going to do full replacement of the view
melanierichards: the part sof the shadow DOM must be labelled with 'part' , and must have all the requisite parts
melanierichards: Controller needs to know which parts it's expecting, so can wire things up based on that.
melanierichards: With either of these two solutions, we expect controller control to provide a lot for the web developer
melanierichards: Would still provide ... and acessibility semantics
melanierichards: Can also wire up correct behaviors, like keyboard interactions for opening/closing the pop-up and selecting options
melanierichards: those would all be provided by the platform, rather than something the author has to provide
melanierichards: In order to do all of this, we require some standardization
melanierichards: So standardization of anatomy of control
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
melanierichards: All of the screenshots here are from Open UI research
melanierichards: We also have to define the states the conrol can be in
melanierichards: Also need to standardize required behaviors
melanierichards: How does the control transition from state to state?
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.
melanierichards: Question: what process do we need for holistic control standardization?
gregwhitworth: We want to have this approach every time we talk about a control
gregwhitworth: whenever someone wants to add a control
gregwhitworth: want to do a thought experiment to make sure we're doing the best design of the conrol
gregwhitworth: and wrt full extensibility, need to define the behaviors
gregwhitworth: if we don't define the behaviors, then author can't know what to extend and hook into
gregwhitworth: Controls are ultmately a composite of everything
gregwhitworth: All of these companies, everyone building a control or component, you start with a design
gregwhitworth: and ultimately what ends up happening is
gregwhitworth: they go and look at the existing specs, HTML/DOM/ARIA/CSS/ etc.
gregwhitworth: they crowd-source
gregwhitworth: Ultimately produce a blueprint
gregwhitworth: Quite a few have user research, e.g. on a touch deveice, this is what's the best from user research
gregwhitworth: Maybe very insightful bug filed, but not shared outside their tracker
gregwhitworth: We want a holistic approach to defining these components, one place to define the blueprints
gregwhitworth: for the entire web platform
gregwhitworth: The composite standardization of the control
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
gregwhitworth: want to have these all defined within open UI
gregwhitworth: We might not end up moving some of these into the Web platform
gregwhitworth: Example, skeleton component.
gregwhitworth: not enough consistency of anatomy to put into HTML
gregwhitworth: but common terminology used
gregwhitworth: went to ARIA and asked a new model, came back with use existing stuff this way
gregwhitworth: Anyone can come and implement against this
gregwhitworth: So basicaly process I'm putting forth, when new pseudo-elements come in for file or range,
gregwhitworth: take to Open UI to define what that looks likes
gregwhitworth: if CSS needs a pseudo-element, then that gets defined in CSS pseudo spec, along with other primitives
gregwhitworth: ultimately, that's the procedural discussion I'd like to have
gregwhitworth: That's the end of the deck.
gregwhitworth: Now want to come back and talk about each tree :)
gregwhitworth: So want to take a 15min break?
gregwhitworth: next topic, we'll be discussing the problem
gregwhitworth: might be pedantic, but want to resolve that it's a problem
<br duration=15min>
<TabAtkins> Yup, having slide context with the convo is useful.
<boazsender> gregwhitworth: that slide link didn't work for me
<astearns> boazsender: it works for me in Edge and Firefox on the Mac
<fantasai> s/Xxxxx -/Fully Extensible - standardization of a control's anatomy, states, behaviors, allowing re-using controller code via defined parts/
<gregwhitworth> Youtube video is here: https://youtu.be/2S2nSqh6EUw
Slides are now archived at https://lists.w3.org/Archives/Public/www-archive/2020Oct/att-0002/OpenUI-control-model-definition.pdf
Problem Discussion
gregwhitworth: the proposed resolution I'm getting toward is "webdevs recreating form controls is a problem"
gregwhitworth: may seem pedantic, but it's our first goal
astearns: I don't thin kit's a problem for webdevs to make their own controls. We shouldn't *keep* them from doing it.
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"
fantasai: It's a problem they feel the need to, in so many cases
levithomason: The problem is that they're all creating the same thing that already exists. If they were creating something specific that didn't exist, that would be OK.
nicole: in my previous incarnation i spent 5 years with a business i founded to fix people's broken front-ends
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"
nicole: But actually almost all the code i had to write was the same for everyone
nicole: A thin layer of different branding, but ovrall the same set of components
nicole: So for me it seems like a *really clear* cowpath to pave
jensimmons: authors creating their own form controls from scratch, ignoring html, being stuck only with JS as their tool, is a problem
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
jensimmons: I dont' think it's a problem tha tauthors have something powerful letting them do this
jensimmons: a lego kit letting them hook into this all is complex, but it's more semantic
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
una: Problem here is not giving devs the tools they need to buid what they want. a11y issues, everyone recreating the same form elements
una: Like Nicole said
una: We've heard and seen time and time again, that users need these browser features, and devs aren't giving them
<Zakim> 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...
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
jcraig: Jen state dmost of what I wanted, and Una. The primitives are lacking.
jcraig: ONe thing to add, the problem is that with the exception fo a few simple controls - clickables/toggleables like radios, checkboxes, buttons - I've *never* seen *custom* controls done in a way that includes all the a11y.
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.
<jamesn> +1 to jcraig a11y comment
jan: I agree it's a problem, but I think more in economics - if you consider a control, today controls are fairly monolithic
jan: A select might have, say, 40 different things it's trying to do - layout, styling, presentation, behavior
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 replace 3 of them
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).
jan: So I dont' think of recreating the entire thing
jan: Devs need a way to do this alteration in a proportionate-cost way
Kaelig_: Agree with a lot of this, and the way the problem is written now.
<jensimmons> +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.
Kaelig_: The platform doesn't allow peole to do the right thing.
Kaelig_: Even if you're a11y-minded, you're gonna break a11y somehow, somewhere
Kaelig_: Enabling the interaction model to be reused, would be fantastic
miriam: I'm currently living Nicole's 5y-ago experience
<bkardell_> 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
miriam: There's different layers of needing to rebuild.
miriam: There are times I need the full extensibiility, but often I need various steps in between
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"
<fantasai> TabAtkins: ...
<fantasai> TabAtkins: It's really important to understand how far browsers relying on OS-level controls are willing to go
gregwhitworth: We literally get to that in a sec
<fantasai> TabAtkins: If we make problems that are only solveable by custom controls, can only solve problems solveable by Chrome today
<fantasai> gregwhitworth: We'll get to that. i just want to agree that there's a problem.
jan: Wanna confirm there's a problem here, like acknowledging it.
jan: is the question about *this formulation* of the problem?
gregwhitworth: This ordering is on purpose, want to agree on the problem first then talk about solutions
gregwhitworth: So can we minute that nobody thinks we *shouldn't* address this problem?
<JonathanNeal> I also agree this is a problem I would like to solve.
fantasai: Take greg's resolution as in his slide?
astearns: I think Jan was saying that's not *all* we need
gregwhitworth: Right, but I want to address the additional parts ina bit
proposed resolution: Web developers needing to re-create a browser's form controls is a problem.
Resolution: Web developers needing to re-create a browser's form controls is a problem.
gregwhitworth: Definition of a control
gregwhitworth: taken from openui
gregwhitworth: No normative dfn
[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.
hober: The high-level dfn seems fine.
hober: The word "component" has a lot of v specific meanings on the web
hober: Might be good to avoid using this word to avoid confusiong
gregwhitworth: Would it be worth defining a component?
<JonathanNeal> suggestion for the name: widget
Agree with hober, btw, "component" is an overloaded word already
<bkardell_> widget is used in html and aria
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.
nicole: Like twitter widget, or commenting widget.
<BoCupp> A control is an *element* that manages user interaction?
<levithomason> Agree with Nicole on "widget" definition not suitable to this case
<melanierichards> +1, element seems sufficient
nicole: I think generally speaking, people use "component" and "control" interoperably
<una> "Element" is what came to mind for me at first, but I'm not sure its better than component
<boazsender> element is smart
<boazsender> (I think element is a smart substitute)
astearns: Suggestion from IRC is "element"
nicole: Doesn't that usually indicate a singular element?
fantasai: Can we just add a note to bikeshed the term later?
levithomason: Greg, on this dfn, does this exclude button?
gregwhitworth: No, I'd expect this to include a button
<jensimmons> from a thesaurus: part, element, ingredient, constituent, fundamental, unit, factor
gregwhitworth: A button takes in user interaction.
Just making it clear: the problem here is the conflict with "web component"
Which is already an existing concept that means something specific.
<astearns> perhaps a 'design component' then?
gregwhitworth: So a button is a control
levithomason: So does that mean a component doesn't necessarily manage the state? Unless CSS pseudoclasses count as stateful.
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?
<whsieh> are progress and meter elements "controls" as well? these aren't user interactible
bkardell_: Based on tess and nicole, ARIA and html use "widget" for this.
gregwhitworth: Do we want to bikeshed the component, but take as given that the general meaning is correct?
hober: The first line of this, "component" is the load-bearing term.
hober: Hard to take a resolution on it and just say to change the term later, if that word does all the work
astearns: Can we just remove the word? "A control manages user interaction"
levithomason: Was gonna similarly suggest we remove the top entirely; the second paragraph says all the same stuff, in more detail.
gregwhitworth: The lower says "component" too tho?
<JonathanNeal> 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.
<BoCupp> 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.
<boazsender> a control manages user interaction, including changes in states and data
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
<gregwhitworth> BoCupp: can you speak up?
boazsender: I put some text in IRC suggesting we remove/clarify some detail
<nicole> I like Boaz's definition
cbiesinger: I think we should reuse ARIA's dfn, would be helpful to use the same terms to hook into a11y
hober: Consistency with ARIA sounds good
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"
una: Think removing the term entirely makes it too broad
Francis_Storr: WCAG uses "component" and has a dfn for this
Francis_Storr: Linked it
<Francis_Storr> w3.org/TR/WCAG21/#dfn-user-interface-components
<jamesn> ARIA widget definition - Widget
<jamesn> 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).
<levithomason> 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.
nicole: I wanted to speak to matching ARIA dfns
<levithomason> Above based on feedback so far.
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
<bkardell_> +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!
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
<nicole> +1 to UI components
<levithomason> Agree fully on following design systems. These are the things that define the web.
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
<jcraig> +1 to Nicole's suggestion to follow the terminology from design systems, not basing them on ARIA controls or patterns
jensimmons: In the context of design system, "component" has a meaning, "web components" has a meaning. Important to put some time into.
jensimmons: But this isn't the right place to put time into it.
<una> +1 I liked msumner suggestion of "UI component"
<levithomason> 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.
<levithomason> Agree on moving on.
astearns: I'm seeing enthusiasm for "UI component". Could resolve to take that for now, and open a bikeshedding issue.
<boazsender> +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/
una: I think "UI component" helps identify what type it is, and adds to specificity of our exact topic
<melanierichards> (for UI component)
hober: Going back to Jen's comment, we should have this convo elsewhere, it might take longer than we have here.
<gregwhitworth> I can re-open this one: https://github.com/WICG/open-ui/issues/81
hober: What part of resolving on this definition is required for the rest of the convo?
<boazsender> +1 gregwhitworth I can post my suggestion there
gregwhitworth: Don't think it's needed yet.
<BoCupp> Like the idea of moving on and also liked this suggestion from Francis for whenever we revisit it: https://www.w3.org/TR/WCAG21/#dfn-user-interface-components
<JonathanNeal> Sharing my enthusiasm on bikeshedding the term, following Jen’s take that it’s important and it needs more time.
gregwhitworth: Outside of the term itself tho, seems like people are okay with the rest of the definition.
<levithomason> 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.
levithomason: Sounds like everyone agrees to not solve it right now.
<bkardell_> +1 to move on if we can, I think we agree "what we are talking about"
gregwhitworth: I'll reopen the issue and drop that dfn in
<jensimmons> I don't have a "problem" with what this is now, I just think we can write & will need a better & more rich definition that'll be more powerful... and we can't do that right now.
<br until=":05 after the hour">
<JonathanNeal> </br>
<JonathanNeal> :P Sorry, i just saw the <br> tag not self closed and it’s a habit.
<gregwhitworth> Ok, added the comment of the updated proposal here: https://github.com/WICG/open-ui/issues/81
<JonathanNeal> I didn’t think about what that would mean. Sorry.
<fantasai> yeah, if you're going to close <br> you gotta do it *after* the break, not right at the start :)
<JonathanNeal> I have just made a personal resolution to stay out of void element humor.
<BoCupp> Back to the control definition for a sec while we are on break... in the context of HTML we could just list the specific elements you want to call a control. I guess it depends on what you want to use the definition for.
<fantasai> Current and future elements :)
<fantasai> so that wouldn't work
<nicole> Yeah... including examples might help, but couldn't be exhaustive, I think
<BoCupp> We could just add to the list as new elements are created and avoid any ambiguity.
<fantasai> then you can't talk about the element as being a control until it's added
<fantasai> The definition isn't a list of elements.
<fantasai> It's a concept, and certain elements fall under that concept
<BoCupp> OK, it might be helpful to list all the elements we think fit the definition and decide what they have in common.
<gregwhitworth> bocupp - depends on the audience I suppose and this is then where we get into where this should live
gregwhitworth: So next step is specturm of customization
gregwhitworth: Jan put it as "varying stages of use-cases we can unlock"
gregwhitworth: "noramtively" is strong, but I'd just like a place to define these buckets of customizability
gregwhitworth: So if someone comes down later and proposes something in CSS related to these topics, they'll have some terminology to use
gregwhitworth: Would also like to have concrete process for each of these buckets
gregwhitworth: Back to Tess's point earlier, dunno if we need to land on these definitions now, just want it to live somewhere
astearns: These are buckets for features, and each bucket has certain things we want to consider when evaluating proposals
astearns: But this isn't a progression
astearns: Coudl have an extensible control that has no hints, for example
gregwhitworth: yes
gregwhitworth: Many buckets would be interlocked, but not a progression. Progression of *use-cases*
astearns: Yes and no. A use-case for hinting might not be addressed at all by a fully-extensible solution if the use-case is "i just want a simple switch to change styling"
jan: Reason I liked the economic statement of the problem is there are many ways to hit it
jan: So like if there are 10 things the component does, rather than saying "here's the full component, you can do whatever", another way is giving pieces that they can customize individually
jan: So one way to solve the "customizable select" problem is to make the select very customizable
<heycam> RRSAgent: pointer?
jan: Another way is to present all the parts of a select and let them do whatever with them.
jan: So not convinced yet that "fully stylable/customizable" is the right way to do this
gregwhitworth: What's the diff between "fully customizable" and "expose the pieces"?
jan: it's a question fo what you're starting with
jan: If you start with a baked-in <select>, and there's ways to twist and contort it, that's one answer
jan: Another answer is having a bunch of mixins or library code that's a precise impl of what the native does.
jan: Those look like different answers
gregwhitworth: That "sub elements" is what I'm hitting on
gregwhitworth: <select> is a partiuclar type of contorl, with a meaning
<nicole> "fully styleable and customizable" is balanced with components that don't try to do too much. e.g. you don't want a swiss army knife component. It becomes too hard to understand.
gregwhitworth: There are sub-pieces to that. You can get those behaviors on their own.
<astearns> +1 to nicole
gregwhitworth: Like having a tag component is a commonly requested thing, would be good to let that be slotted into a <select>
gregwhitworth: We're trying to enable as much reuse as possible.
gregwhitworth: So don't think there's disagreement here, whether we do it as smaller subcomponents, or capabilities that are separable.
jan: I feel like "fully stylable/extensible" presume a native element being adapted
jan: Might be productive, but dunno if that's the only mindset we can pursue
jan: Think it would be helpful to consider a more building-block approach to solving controls
gregwhitworth: Don't understand what's missing here. A <select> is made of smaller pieces, and we might define that way.
<nicole> what is an example of smaller pieces?
levithomason: I think on this slide, I'm just seeing a spectrum of capability - can do nothing all the way to can do everything
levithomason: We resolve on defining some steps along that path
levithomason: Separate from *how* we enable that, which I think is what y'all are talking about
levithomason: *could* enable with a tweakable monolithic component, *could* enable as a building-block set of subcomponents, either way works
melanierichards: These solutions arne't mutually excluive
melanierichards: Dont' want to throw out some of the solutions is bc if we only had composable world, we'r eputting onus back on the dev to get everything right
melanierichards: When people do compose their own, we find people missing a keyboard interaction here, or a localization consideration there.
melanierichards: So concerned about a lego-piece solution as the only thing, we're reproducing that problem
melanierichards: So think these can coexist
<fantasai> melanierichards++
bkardell_: Mostly agree with Melanie
bkardell_: subsection of th eproblems that is just tweaking at the edges, relatively minor poking
bkardell_: but then there are things where people would disagree whether what they're doing is even the same component as something else
bkardell_: So for those cases, breaking down our existing controls into course-grained pieces, which you can use to build things that are select-like but not <select>s, is probably a good thing. But overall it's neither one nor the other, it's both.
jan: To the right of this axis is something else - someone who has something totally different they want, barely recognizable as an existing control.
jan: I want the jump to the right to not be starting over.
jan: Just want to keep in mind that the progression should be smooth as we go along
jan: I think some of these boxes are presupposing an answer
<fantasai> TabAtkins: Just noting that this whole conversation seems to touch on exactly the extensible web manifesto core problem statement
<fantasai> TabAtkins: which is in general we should make the platform have as small as reasonable jumps of necessary re-iplementing of functionality just because you need some small change
<fantasai> TabAtkins: Related to economic argument earlier: degree of change you want to do should be proportional to the effort required
<boazsender> +1 this conversation was reminding me of the extensible web manifesto
<fantasai> TabAtkins: Right now you can do very minor tweaks, or re-implement from scratch
<fantasai> TabAtkins: Should be able to tweak the parts you need
fantasai: I think the specturm is a good way to look at the different ways we can modify things
fantasai: I think we have authors that fall into every bucket
<tantek> I like the spectrum approach
fantasai: I think a solution that's one of those buckets isn't good enough
fantasai: We need solutions in each bucket.
<bkardell_> +1
fantasai: The same conceptual control, should be able to appraoch it in each bucket without having to fall back to "fully extensible" each time
<miriam> +1
<una> +1 also!
fantasai: Unsure what we're aiming for in reoslution here, just emphasizing that authors are wanting each of these levels, and shouldn't be forced into one particular level.
BoCupp: Greg, could byou be specific about what you want out of these slides?
BoCupp: Think the examples in each is *representative*, and we want UAs to make each possible
gregwhitworth: The goal is not that we got this perfectly, it's to acknowledge the existence of the specturm
gregwhitworth: fantasai said this - sometimes webdevs just want to reach for a pseudo-element because it's all they need
gregwhitworth: So just want the general agreement on the concept of these buckets
gregwhitworth: That each provides different useful ways to help authors
gregwhitworth: So can we agree on the existnce of these buckets, agree they should live somewhere, and help drive solutions toward them
una: Think it's really helpful to diff between styleability and extensibility.
una: Extensibility can be as simple as adding an icon to a select list's of items
una: Don't think we need to resolve on the limit of that yet
una: But we should have solutions for all of these things
una: People talk about "oh, we can add bits and pieces here", but when you break down the anatomy, you see that deep extensiblity is actually required to enable some of these "simple" additions
una: So the entire specturm ends up being needed even if you think you're just enabling "simple" styling
jensimmons: I spent a bunch of time this past week thinking about this
jensimmons: Like thinking about separating style and extensibilty
jensimmons: Does think we'll be thinking about these as a spectrum of buckets
jensimmons: Some will match the OS more than others, etc
jensimmons: So I think this is exactly the direction we need; the names, the number of buckets, might not be in love with. But the spectrum itself, I'm totally for it
jensimmons: The more I've looked at this, the more it looks right
nicole: I think this list is a good starting point
nicole: So I think as a jumping off point, this list serves well
boazsender: I also think these buckets ar egood for authors, to help them reason about what they can or can't do
astearns: Seems I'm hearing consensus that this is a good way to break up the work
<tantek> Might also be useful to cluster different form control customization use-cases (as explicit use-cases) in these buckets.
gregwhitworth: So two things
gregwhitworth: So beginning of specturm is css-ish, end is html-ish. Think this dfn should live in OpenUI, unless someone disagrees?
astearns: Think that solutions themselves will live in CSS or HTML, but OpenUI has, in W3C terms, a horizontal-review function for UI control customizability
<levithomason> Agree on Open UI as some kind of "rating" or "category" on the research pages. This is perfect for analyzing existing UI components.
astearns: So these buckets become evaluation criteria for OpenUI to use
gregwhitworth: Right, rather than HTML referencing CSS or vice versa, since both have claims on these, we'd put the actual definition in OpenUI.
levithomason: Seconded.
levithomason: OpenUI is especially suitable for horizontal classification. Also would be applied on aresearch basis to the existing elements out there
gregwhitworth: So does someone have a strong desire to have these live somewhere in CSS, HTML, or elsewhere?
<bkardell_> do you expect them to be normatively referenced or just used for discussion?
<tantek> definitions of the buckets sounds like an "explainer" kind of thing, either optionally standalone, or as an informative section of the relevant spec
boazsender: To horiz review, there are parts of the w3c that do that. there's process documentation...
<fantasai> tantek, yeah -- either informative section of a spec or in a Note
boazsender: Don't know if those reviewers have areas for notes
boazsender: what is the 5-year picture for this?
<tantek> fantasai, yeah informative section in a spec makes sense, not sure we even need something as formal as a Note
boazsender: dunno if w3c has bandwidth for this kind of research; is there an idea that this would land in a standards body?
gregwhitworth: i would expect this to be a page on OpenUI that explains this
<bkardell_> I think it's fine if that lives in openui
gregwhitworth: So when a spec is written, could have a note referencing the OpenUI page about what bucket it's addressing
gregwhitworth: So like 'accent-color' would define that it's a "hint" category
<tantek> fantasai, are you looking to try to capture the evolution of these buckets somewhere in w3.org space? curious if that's what you're getting at
gregwhitworth: And just generally to provide a set of common terminology
fantasai: I just dont' think HTML is the right place for this to live, since so much of it is styling.
<tantek> +1 agreed with fantasai
<fantasai> If that's what's wanted, sure. I'm OK with it living elsewhere so long as, if we want it to be referenced by specs, it's a long-lived space that can actually serve as a referece
jensimmons: Don't care where it lives, OpenUI is fine. When it comes to resolutions on buckets closer to CSS side, would be good to bring CSSWG in.
<tantek> OpenUI is a CG/TF right? (not a WG AFAIK)
<fantasai> Like, if we're formally referencing this document from one of our specs, it needs to exist 20 years from now
astearns: I definitely expect CSSWG to have input into these buckets and their criteria
astearns: Tantek had a question about OpenUI status?
<bkardell_> it's wicg
gregwhitworth: It's a CG
gregwhitworth: Been purposely staying out of discussionsa bout our exact status
<tantek> CG makes sense, and I agree with jensimmons point about resolving in CSSWG
gregwhitworth: Re: Jen, completely agree, we'll be pulling in CSSWG
astearns: So proposed resolution is: define a spectrum of customizability, have OpenUI define these buckets
<tantek> I believe the CG can publish "reports", so perhaps that's a good way to get the buckets documented
fantasai: And authors can operate at any of the levels
fantasai: Not just one of them
astearns: Realistically I don't think we can develop solutions in every bucket at the same time
fantasai: Right, but it shoudl still be our goal to allow customization at every level
Resolution: define a spectrum of customizability, have OpenUI define these buckets
gregwhitworth: So based on the problem at the beginning, ultimately not providing webdevs the ability to use what they need and making ti as simple as possible, creates end-user implications
gregwhitworth: impl willingness has to exist
gregwhitworth: So discussion here, from a browser or other deep dev involvement, what's your level of engagement and interest?
gregwhitworth: So I'd love to understand, from impls perspective, where on the specturm they're willing to go
gregwhitworth: Solely in the A camp, or willing to do Hints (b), or pseuod-elements (C), or further
gregwhitworth: Also want info from design libraries/etc about what level they *need* before they can actually use them, rather than reinventing.
gregwhitworth: Ultimately goal here is to increase utilization of the platform.
gregwhitworth: Want to make sur eI'm investing my time in those most productive areas
<jensimmons> no
gregwhitworth: [rephrases what i wrote above]
gregwhitworth: what i'm trying to udnerstand is, from an impl, to what level are you willing to explore?
gregwhitworth: managing expectations, dont' want to assume we're all on board then be surprised
gregwhitworth: And like, if we only go to C, will libraries actually use them?
fantasai: I'm not an impl, but similar questinos have come up in CSSWG
fantasai: Think there is interest from impls to do all of these things
fantasai: But there are definitely concerns about matching platform conventions, at least when authors aren't explicitly trying to override
fantasai: So ther'es a willingness to explore this space, in a discussion where all the vendors are participating
fantasai: And where the levels of consistency with the platform is taken into account
fantasai: Don't thinkw e want to go to a place where everyone renders form controls the same way
fantasai: But at certain levels of customization, you want 100% interop
fantasai: So shoudln't jump to "same" as the basis of interop *immediately*.
fantasai: So there's an interest in each of these, but need to make sure we're balancing concerns.
whsieh: Curious about how this plays out in e.g. iOS
whsieh: For select for example, it'll show up in the keyboard
whsieh: It uses native tech, not customizable in CSS
whsieh: So are we getting standard rendering across all platforms? or can we adapt to device
gregwhitworth: Perfect example of what I'm referring to. To enable partial styling, or full styleability, ultimately yes you will need to be able to style that content
gregwhitworth: Might pass in an image, but that doesn't go far enough as you saw i nthe examples
gregwhitworth: complex examples
gregwhitworth: So that's why getting into custom attribute or new elements
gregwhitworth: if we go for 100% interop, to allow ppl to level set and go where they need to
gregwhitworth: have base style sheet, going to adjust part to my needs
gregwhitworth: would have to be in web tech
gregwhitworth: taking your impl as an example
gregwhitworth: ...
gregwhitworth: That introduces new interop problems like event timing
gregwhitworth: far right of the scale has these consequences
gregwhitworth: Would iOS say absolutely not, our scroll wheel doesn't allow that
whsieh: Helpful
whsieh: I wouldn't say it's completely non-styleable
whsieh: but we'd have an allow list of certain styles, that we would accept to a certian degree
whsieh: We can't handle a 999px padding
whsieh: but a little bit of spacing, maybe can do
gregwhitworth: So can fall in the Limited bucket
gregwhitworth: not necessarily bad
gregwhitworth: If you have a site with a more complex select picker, e.g. might want a full grid layout inside, need to build their own
<nicole> stylable isn't the same as normative is it? e.g. let web devs style things, but different browsers have different default style values?
whsieh: There's also watches to keep in mind
gregwhitworth: If we can pull off views being adjusted inside this, points to larger paint point of web platform in general of being able to standardie models in controllers
gregwhitworth: DOM structures to change out the view
levithomason: I think there's 2 answers to Greg's question from library point of view
levithomason: We always go to Bucket E
levithomason: But that isn't the baseline necessarily
levithomason: We go there because what's in the platform right now requires us to drop the entirety of form controls and go to something custom
levithomason: If platform had more capabilities, could D-E or C-E
levithomason: Features of modern web applications in web don't differ much from library to library, just differ from web platform to library
levithomason: So if web platform had more capabilities, then could use it
levithomason: but need it to be fully styleable, because corp wants pixel-perfect across platforms
BoCupp: Statement to answer greg's question
BoCupp: On the MSFT web platform team, we're willing to explore full spectrum of capabilities
BoCupp: My team recently invested in refreshing all of the controls in the Chrome codebase
BoCupp: and exploring the far end of the spectrum
BoCupp: Actively working on proposals for the middle part of the spectrum
BoCupp: Ideas about customizing control UI
BoCupp: If we explore more, are implementers willing to put $$$ behind it, yes we are willing
BoCupp: So long as it doesn't wither in this conversation
BoCupp: Wrt customizing the native iOS UI for something like Select
BoCupp: Would you also be willing to produce an implementation for in-page support for an interoperable select control
BoCupp: for when devs are trying to achieve further ends of spectrum?
BoCupp: There's not a select popup there
BoCupp: So you'd have to write new code, would you try?
whsieh: Right now, that's kind of the reality
whsieh: If you visit a desktop page that has a selct built up from DIVs, that is the experience
whsieh: I think it's important that we keep the default select using a form factor that is more suited
whsieh: I don't want to end up in a situation where devs test primarily on desktop platforms
whsieh: and don't realize that their selects could look different in different mobile platforms, and cause UI bugs that way
<bkardell_> not only mobile platform I think - embedded platforms too?
whsieh: I think if we left it to the UA, we could make sure everything is laid out nicely in the input view area
gregwhitworth: I completely agree, which is why I refer to base style sheet
gregwhitworth: From business perspective, nothing in there that is a web content creates
gregwhitworth: but you all providing feedback on what makes a great mobile experience
gregwhitworth: leveraging responsive web design in that base style sheet
gregwhitworth: would provide a good base to build on top of
gregwhitworth: Like Chrome, we agreed to desgn the controls
gregwhitworth: and then adjust that
gregwhitworth: You and the Android team bring the most knowledge about what makes a mobile experience
gregwhitworth: as new form factors come out, maybe it isn't feasible to achieve
gregwhitworth: I don't want to get into hypotheticals of can't ever do this because of hypothetical form factors
gregwhitworth: Maybe need new styles, maybe need new anatomy
gregwhitworth: No browser does it this way, but majority of Web component libraries have a unifed form factor
gregwhitworth: ...
brandonferrua_: Just want to provide perspective on Salesforces' problems
brandonferrua_: We fall in the ranges of like C,D, sometimes E
brandonferrua_: I thin it depends on the type of solutions being proposed
brandonferrua_: Our customers use our platform
brandonferrua_: we're providing a styleable solution for them
brandonferrua_: Styling interface
brandonferrua_: e.g. CSS custom properties
brandonferrua_: we want to share those brand expression properties among all the form controls
brandonferrua_: so that's where I think fully styleable, we find ourselves in that bucket often
brandonferrua_: Limited is great for standard element
brandonferrua_: but since we're focused on building custom solutions for our customers, we find ourselves primarily in D, and sometimes in E if we want to manage how do we change the expected expeirence of a component on mobile vs desktop
brandonferrua_: or a situation where semantically, say through ARIA definition, we're trying to re-use aspects of a combobox but add additional functionality e.g. global search vs inline picklist
brandonferrua_: there's elements between those things that we want to share
brandonferrua_: but sometimes need to do part replacements, to get different level of functionality
emilio: From Gecko's perspective, we're looking to make our form controls not rely on the OS mostly for sandboxing reasons
emilio: That said, I want to echo someone's concerns about mobile
emilio: I've broken so many forms on mobile forms
emilio: desktop viewport
emilio: if we do something like we do on desktop
emilio: it would be so unusable
emilio: but that's a different discussion, whether we need to do this on mobile
emilio: allow more styleability
emilio: if using mobile viewport, need content to be viewable
gregwhitworth: Where on the spectrum are you investigating?
emilio: Basically, that unblocks going from B to E eventually
emilio: Prerequisite for that
emilio: Right now we rely on .. APIs
emilio: Can do very limited set of customization for controls
gregwhitworth: Once you get there, willing to investigate all boxes on this spectrum?
emilio: Yeah, think this is a problem worth solving
emilio: I think we're interested in investigating this problem space
heycam: Ongoing work to replace
heycam: something that doesn't match platform
heycam: will unlock chance to do hints
heycam: It is a blocker for the more extensive customization
heycam: more work would be needed to implement support for that
heycam: futher end of the spectrum excites me
heycam: bunch of work in Open UI, I think this is acool form controls style that's commonly used across the web, and we need to have a facility for it in the platform
heycam: I can't commit to resources or timing, but we're interested in making D/E possible
heycam: But I think it's also worth investigating the lighter end of hte spectrum
heycam: I think it's important to address those use cases as well
Kaelig_: Same boat as Brandon
Kaelig_: I've seen similar themes at Shopify
Kaelig_: Examples
Kaelig_: Use case we have legacy code base, want to restyle to our new design language
Kaelig_: Salesforce pre-Lightning, and without touching markup as much as possible, wanted to restyle their UI
Kaelig_: Same thing happening in Shopify right now
Kaelig_: if we changed markup and added containers etc.
Kaelig_: will end up with a lot of layout bugs
Kaelig_: the best place to be would be C
Kaelig_: using pseudo-elements, restyle existing UI
Kaelig_: wrt React library, we can modify anything there, so can be in D and E
Kaelig_: Our API to consumers of the component library would be the same
Kaelig_: so we can change internal to use fully-styleable and fully-extensible techniques
Kaelig_: but old code where we were shipping markup, it's different
Kaelig_: so B and C would fit in more there
jensimmons: I think this spectrum is really interesting, and as I look at it more and more
jensimmons: I think on the B end, the browser is going to take responsibility to make sure e.g. color contrast is enough, and provide defaults that can't e overrideen
jensimmons: author has to let go of control
jensimmons: but on extensiblity end, want specific control over specific parts
jensimmons: At that B/C end of spectrum, author isn't sure quite how it'll come out
jensimmons: less clear what code will do exactly
jensimmons: but on the other end, code will do exactly X
jensimmons but wondering if it's more of a binary
jensimmons: but ... author does none of that
jensimmons: falls back to C
jensimmons: if can't do E
jensimmons: why would that happen? might happen...
jensimmons: I'm not saying this as an implementer, but as an author advocate and user advocate, and soeone who's been around long enough to see how things change drastically when new devices show up
jensimmons: Most extensible, give authors what they want end of spectrum
jensimmons: we'll still need a way that it doesn't apply
jensimmons: when I think about telephone input
jensimmons: and how it brings up a keypad
jensimmons: I don't think we're proposing that we're going to extend Web so that Web can re-extend or rebrand keyboard on phones
jensimmons: or webvr or some other device
jensimmons: there always will be some potential for cutting edge, where browser is going to need the ability to say "I get your extensiblity, but I'm about to invent something new, and so we're not going to do your thing and do this other thing instead"
jensimmons: Say this based on what greg said earlier
jensimmons: for the sake of authors and users, browser will have ultimate control
<bkardell_> Select, as is today is still tremendously useful today: http://rainy-periwinkle.glitch.me/permalink/479923459778471005ca9552acabec522cd095be05ae8ee28b8f325819f383d7.html HTTP Archive measures public home pages, and I'm not sure I think of selects as being on a lot of home pages - yet it is still great. With minimal changes we can make it more useful - - then there is ... more.. where its not.. those are real, and challenging... we have to
<bkardell_> think about how..
bkardell_: I think I agree with most of these things
<boazsender> +1 jensimmons
bkardell_: as it stands today, as much as we're saying ppl don't use them, select as an example, is one of the most-used elements
bkardell_: it is incredibly used
bkardell_: Some of the things closer to the left will increase the number of ppl who will use it
bkardell_: further we get to the right, getting into use cases where extending and taking control
<jensimmons> I should have ended with — I hope the question at hand isn't a demand to say we will for sure create something where Authors have 100% control over the controls. Because I don't think we have to go 100% there. I think it'll be more like 90-95% there.
bkardell_: don't know what's the best way to do that
bkardell_: it seems like those ones on the left are obvous "we should do them"
bkardell_: and one on the right, we have to admit they're real, and no amount of giving will cover everything companies want
bkardell_: so we need to give them tools so they don't need to rebuild the universe
melanierichards: So want to go back to something Bo touched on
melanierichards: MSFT is interested in full spectrum
melanierichards: failed to mention, that some of the ? for full extensiblity came from explainer shared on IRC
melanierichards: and developing primitives
<gregwhitworth> the explainer is linked at the end of the deck as well
melanierichards: we've talked about things willing to explore
melanierichards: is there anywhere in spectrum where implementer thinks it's a non-starter
melanierichards: different idea on how to solve?
melanierichards: anywhere we can't move forward?
msumner: Start of conversation, greg asked what would get you to use it
msumner: As an author, if I could just have multiple text nodes in an option element
msumner: I wouldn't use a custom library
msumner: and if I could just change the color of the caret a bit
msumner: A lot of us would be able to switch to using native select
msumner: as MVP, those two would make me so happy
gregwhitworth: Love that you brought up option thing
gregwhitworth: How quickly propose to allow option to take arbitrary content? So many use cases for custom selects right there
gregwhitworth: If you look at "additional functionality", we asked what functionality
gregwhitworth: and most of them were wanting an input at the top that allowed searching the options list
gregwhitworth: So I love that there's a spectrum we're willing to explore
gregwhitworth: feels like everyone agrees to go after these
gregwhitworth: There may come a device no one ever cosidered before, but not unsolveable problems
gregwhitworth: Ultimately I got out of this, let's go define all of these somewhere
gregwhitworth: want to stress all the use cases
gregwhitworth: great for ppl to dig into the use cases in Open UI and propose solutions
gregwhitworth: Lot of low-hanging fruit
gregwhitworth: not just the far end of the spectrum
gregwhitworth: Sounds like component libraries will benefit.
Where to do the work
gregwhitworth: Controls end up being a composite of entire web platform
gregwhitworth: what I would love to do, basically, to the web platform as a whole
gregwhitworth: when a form control is proposed
gregwhitworth: want to get component design folks and others from web platform in one place to filter the discussions
gregwhitworth: rather than have a few of us hopping across WGs and trying to get an idea to coalesce
gregwhitworth: Do the research to ensure not plugging into a corner
gregwhitworth: are we sure this pseudo is solving the problem?
gregwhitworth: Want to suggest anything that has to do with controls, not defined in Open UI, but brought to Open UI to have the composition defined
gregwhitworth: So whether be touch or clicks, enable the full extensiblity, in addition to part defintions, will need that for fully extensible
gregwhitworth: Have to define the parts
<bkardell_> I am on for this topic
Previous
myles: quesitons asked fairly direct, want to provide a direct answer
myles: It is true that some web developers need flexibilit in buckets D and E
myles: Nothing we do will make that go away
myles: So of course, we would love to explore buckets D and E
myles: That's the reality of what's required on the Web
myles: we're very interested in what solutions to that would look at
myles: we're also very interested in what fallback would look like
myles: what are responsibilities of browser vs web page
<bkardell_> agree with myles - that's what I was saying too... I believe myles said it better
myles: how can browser fall to buckets A, B, or C
myles: And for designers/developers who don't need the full flexibility of D and E, can we provide solutions for them in A/B/C
Process
gregwhitworth: Controls begin in Open UI to define their parts
gregwhitworth: Proposed process in which form controls are holistically proposed
gregwhitworth: current proposal is if you're bringing forth new controls or new components
gregwhitworth: those start within Open UI
gregwhitworth: e.g. File Input pseudo element
gregwhitworth: Should be defined in the CSSWG
gregwhitworth: but that defines a part
gregwhitworth: want tha anatomy to be thought about in Open UI
gregwhitworth: events and ? would be specced in respective WGs
gregwhitworth: Open UI would define what the anatomy and composition of the parts of the form control
gregwhitworth: If there's an agreement of base style sheet, requires anatomy
gregwhitworth: define in CSSWG
<gregwhitworth> https://www.irccloud.com/pastebin/1uCB1Lyv/
Proposed Resolution:Control definitions will begin in Open UI to have a complete specification created for all parts, states and behaviors.
New CSS pseudo elements, classes or primitives will be standardized in the CSSWG. New elements, attributes or DOM events will be standardized in WHATWG. New ARIA roles will be standardized in the ARIA WG.
bkardell_: Important distinction. Greg said form controls.
bkardell_: ARIA contains many roles, no parity with HTML elements today
bkardell_: for widgets, as it refers to them, those are not mainly the ones that don't have parity aren't input collection
bkardell_: The only thing like that that exists together is summary details
bkardell_: summary details is an example we would follow that is not OS-provided
bkardell_: components that we would allow you to really poke in
bkardell_: I think this is an easier class of problem
bkardell_: what about those components?
bkardell_: would browsers agree that they would be more open to getting more full extensibility?
gregwhitworth: He's going back to this part of the spectrum, where a lot of the concerns with interop is due to native OS rendering
gregwhitworth: There are other controls, like details/summary that *are* rendered with web tech today
gregwhitworth: So he's wondering if there is more support in browsers engaging in tabs/etc new stuff, given the existence of new web-defined controls?
BoCupp: my first focus has been on <select>
BoCupp: It's on of the least stylable areas, but most used controls
BoCupp: I don't think there's any intent to *not* invest in other controls that don't happen to have some OS or mobile specialization
BoCupp: WAs that the question basically? Are we willing to explore range/dialog/etc?
bkardell_: Greg had mentioned new controls
bkardell_: Does it seem like there is an easier class of problems for new controls to take up with the full story around extensibility?
myles: Confused about the question
bkardell_: We cna move on, didn't want to distract
nicole: Also important to recognize that any of these might be new controls, hard to find the boundary of the controls until you really dive in
nicole: <select> might be one thing, or it might end up dividing into a select and a search, etc
nicole: Dont' think we have to try today to figure out
astearns: As the CSSWG cochair, i assume that you're saying that if someone comes to CSSWG with a proposal for a new pseudo-element for a form control, we should rope in OpenUI for discussion first, and not work on it ourselves without involving OpenUI people
gregwhitworth: Yeah, tho I'm a little uncomfortable with the phrasing
gregwhitworth: So as we're working on a spec, if there's value for a new pseudo-element or property, the issue would be opened in, say, CSSWG
gregwhitworth: Controls stuff, fo rproperties and states, would be done in OpenUI
<BoCupp> Greg, I heard your answer to Alan's question as: yes.
<JonathanNeal> My two cents. I thought Brian’s comment was sort of like “If we want to flesh out ui components in OpenUI before they pass off to their discipline WGs, should we prioritize fleshing out some ui components that are already defined in ARIA but not already available as HTML elements?”
gregwhitworth: Coming back to my proposal, don't want to imply that a spec has to be "complete" before it can be proposed
<boazsender> is this process design / working mode documented somewhere that we could read it?
gregwhitworth: Note that there's overlap between CSSWG and OpenUI membership anyway. So yes, what you said, but don't want to be seen as gatekeeping.
myles: Specific example
myles: Say I'm interested in a font picker. What's th eprocess?
gregwhitworth: You'd come to OpenUI with the idea
gregwhitworth: We'd do analysis, research on existing usages, figure out the anatomy
gregwhitworth: And end up with something that, say, Office could implement and ship.
gregwhitworth: If we have enough agreement that there's a pain point for a new HTML proposal, that's the next step
<boazsender> I don't think it is gate keeping to be clear on what the process design is.
gregwhitworth: We just want to avoid duplication of effort - where we take the proposal to HTML, and then it's all relitigated and redefined
<JonathanNeal> bkardell_: ah, okay. I appreciate the clarification.
gregwhitworth: The composition of the behaviors/states/anatomy should be defined in OpenUI
gregwhitworth: So like for details/summary, those elements shoudl be in HTML, but the behaviors/states should be in OpenUI.
<boazsender> I'm confused because I heard from gregwhitworth what astearns stated, but then greg said this is not the case.
astearns: [asks boaz's question]
gregwhitworth: Yeah, I'm really saying the same thing as Alan, just don't want to act like I'm claiming territory
astearns: I think OpenUI shoudl own its expertise. Not a bad thing to kick things to you and get y'all's opinion before we potentially go down a wasted effort
astearns: If OpenUI is going to have those parts/behaviors/etc, you will have to formalize yourself in W3C
<boazsender> lol
BoCupp: I dont' think it's gatekeeping to centralize expertise
BoCupp: Would love to get the process written down, would volunteer to help
<astearns> s/BoCupp /boazsender /
BoCupp: So, myles would open an issue for font-pickier in OpenUI repo, attend some OpenUI meetings, write some OpenUI docs, then get a resolution to take it to CSSWG for standardization, to WHATWG for the element name, to WCAG to standardize roles
gregwhitworth: Yeah. I just don't want the silos, bc they duplicate effort
gregwhitworth: So yes, open an issue in OpenUI, propose spec text, etc
gregwhitworth: So if font-picker is a new element, we'll discuss bringing it to WHATWG, etc
myles: So if this is gonna be th eprocess, should nail down the scope
myles: How should I know if a new idea should be taken to OpenUI or CSSWG?
gregwhitworth: Want to say that if we're discussing new UI, whether it's in browser or not, it shoudl start in OpenUI
gregwhitworth: So even if it's just an idea for a new CSS pseudo-element, it should still start in OpenUI
gregwhitworth: So we can figur eout its impact on controller and rendering
gregwhitworth: Say we brought accent-color in OpenUI, and heard no webdev interest in it. That would raise questions about whether we want to do it.
gregwhitworth: So yes, anything with new UI on the web platform, changes and proposals start in OpenUI.
myles: So "controls and component rendering" is what I got from that. That feels somewhat broad, and I dont' want to litigate it now, but I want it to be written down at some point.
boazsender: Issue #197 open to deal with that
boazsender: More things to consider including
boazsender: Not just where it ends up, but things like test writing and docs
<astearns> https://github.com/WICG/open-ui/issues/197
gregwhitworth: open an issue, i know there's interest in things like test suites
jan: trying to keep track of responsibilities. think i've heard of four
jan: First is research arm, looking at how people are building components.
jan: Second is, for new elements, based on that research, figuring out their composition and beahvior.
jan: Three is a retroactive identification of existing elements, their consruction/etc
jan: Fourth is extensibility model, ways to extend existing and future elements
gregwhitworth: Extensibility model would be probably in HTML/CSS in some fashion. The dfn itself wouldn't be in OpenUI.
gregwhitworth: Research arm isn't the only thing OpenUI brings to the table. Would hope that's part of anyone bringing a proposal.
gregwhitworth: So the main responsibility I think here is that OpenUI builds the blueprints for what, say, a great font picker is.
gregwhitworth: And ultimately, if we ship that in the browser natively, we'll figre out what elements and pseudo-elements that requires.
gregwhitworth: So if you're wanting to add a new pseudo-element, you're defining a "part" of a control, which is what OpenUI wants to figure out in detail.
jensimmons: Makes a lot fo sense for the big-picture planning to happen in OpenUI
jensimmons: Reminds me of when accent-color came up, there was a question of how it fits into the bigger picture
jensimmons: I think we'll get to a place wher ethe bigger picture is defined, and there's a lot of things we might want to do in a particular bucket.
jensimmons: We wouldn't go back to OpenUI for every single value there; OpenUI will have defined what it means, and CSS can define its interface to those bits.
Kaelig: Curious about next steps, as someone following but wants to be more involved
<nicole> That's part of what w3c is for, right? Everyone has signed to share IP?
gregwhitworth: Good transition. Anyone is open to join open-ui.org
gregwhitworth: So work to do is what tier of officialness we need to get to in order to be recognized
gregwhitworth: I'm proud of this entire group for recognizing that there was a problem
gregwhitworth: I'll follow up in future meetings to make sure CSS/HTML/etc people are looped in properly
levithomason: Seems like there were questionsa bout concrete next steps
levithomason: Thoughts from founding OpenUI
levithomason: OpenUI doesn't yet have all of these things solidified
levithomason: So groups like this should come and help us solidify our role
levithomason: Core idea is that web evolved without standards and platform help for building apps
levithomason: UI in general did this as well
levithomason: Leads that pushed industry forward have been designers mostly
levithomason: OpenUI's stance is that most of th ecreativity has gone on long enough, we should look back at what's become normalized and extract those patterns
levithomason: And then fit them back into standards
levithomason: So not quite as concrete as what's implied by the buckets, but really looking for collab from anyone with expertise
levithomason: Regardless of whether they're in a stadnards body, or author, etc
gregwhitworth: I'll follow up offline any remaining issues, might have Friday overflow for additional topics
<Kaelig> huge thanks to the scribes
<Kaelig> And thanks again for the invite, gregwhitworth, I've learned a lot about how one of these meetings can go, and will reapply that newly acquired knowledge in running my CG meetings.
<gregwhitworth> Kaelig: thanks for coming :)
<fantasai> gregwhitworth, does Open UI have a mailing list?
<fantasai> gregwhitworth, to post the minutes to
<gregwhitworth> fantasai: yeah, hold up
<gregwhitworth> fantasai: public-open-ui@w3.org