- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 17 Oct 2020 11:00:40 -0400
- To: www-style@w3.org
- Cc: public-open-ui@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Joint Meeting with Open UI
==========================
Font picker control
-------------------
- There is a proposal for a font picker control
( https://github.com/tabatkins/proposal-local-font-access )
which can be the starting point for discussion on how to expose
local fonts without having fingerprinting issues.
Holistic approach to control/component standardization
------------------------------------------------------
- The conversation started out with a presentation from
gregwhitworth and melanierichards
- Slides are available here:
https://lists.w3.org/Archives/Public/www-archive/2020Oct/att-0002/OpenUI-control-model-definition.pdf
- A recording of a similar presentation is available here:
https://youtu.be/2S2nSqh6EUw
- They outlined different levels of customizeability for form
controls:
- None - no styleability or extensibility
- Hint - author provides value that UA applies in spirit of the
property
- Limited - styleable elements and pseudo-elements, but limited
in some way
- Fully Styleable - Developers can opt into standardized parts
and structure and base styles that are fully restyleable
- Fully Extensible - standardization of a control's anatomy,
states, behaviors, allowing re-using controller code via
defined parts
- After outlining the problem space the group discussed about if
this is a problem they want to solve.
- Though it wasn't an issue that web developers can make custom
controls, the problem is that they often feel they have to.
- Additionally, when developers do have to make custom controls it
loses all of the accessibility benefits which come from native
controls.
- RESOLVED: Web developers needing to re-create a browser's form
controls is a problem.
- The group moved on to reviewing some of the proposed
definitions to use when creating requirements.
- There is no normative definition for control so the proposal was
"A control is a type of component that manages user interaction.
The control has controller code that manages changes in the
component's state and its model based on user interaction with
its parts."
- Using the word component was problematic since it has different
meaning in other places. There wasn't an agreement on the right
word to use but some possibilities raised were:
- UI component
- Widget
- Design component
- Element
- The rough definition at the end of the discussion was "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."
- Discussion of the definition will continue on github:
https://github.com/WICG/open-ui/issues/81
===== FULL MINTES BELOW ======
Agenda: https://github.com/WICG/open-ui/blob/master/meetings/telecon/tpac-openui-csswg-oct-2020.md
Present:
Tab Atkins-Bittner, Google
Christian Biesinger, Google
Tantek Çelik, Mozilla
Daniel Clark, Microsoft
Emilio Cobos, Mozilla
James Craig, Apple
Bo Cupp, Microsoft
Elika Etemad, Invited Expert
Brandon Ferrua, Salesforce
Mason Freed, Google
Wenson Hsieh, Apple
Brian Kardell, Igalia
Una Kravets, Google
Peter Linss, Invited Expert
Alison Maher, Microsoft
Myles C. Maxfield, Apple, Inc.
Cameron McCormick, Mozilla
Brody McKee, Beamery
Jan Miksovsky, Salesforce
Theresa (Tess) O'Connor, Apple
Simon Pieters, Bocoup
Melanie Richards, Microsoft
Devin Rousso, Apple
Boaz Sender, Bocoup
Jen Simmons, Apple, Inc.
Alan Stearns, Adobe
Francis Storr, Intel
Chance Strickland, Modulz
Nicole Sullivan, Google
Levi Thomason, Microsoft
Greg Whitworth, Salesforce
Scribe: fantasai
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 fingerprinting
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
Holistic approach to control/component standardization
======================================================
Problem Space 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
------------
Slides are here:
https://lists.w3.org/Archives/Public/www-archive/2020Oct/att-0002/OpenUI-control-model-definition.pdf
Youtube video is here: https://youtu.be/2S2nSqh6EUw
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 Microsoft 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 Microsoft 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 fundamental form of the select isn't changed,
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: That is the 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 appearance
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% with regards to missing components
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 painful 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 painful 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 consistent brand and work
well everywhere.
melanierichards: When recreating controls, putting onus on devs to
get it right
melanierichards: and issue around people 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 people 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 hanging 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 code is 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 Styleable, 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 control
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, please 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 people want to change the glyph, what
do we do then?
gregwhitworth: Similar to password field investigation, quickly run
into limitations
gregwhitworth: OK, define 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 selected 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 extensible.
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:
None - no styleability or extensibility
Hint - author provides value that UA applies in spirit of the
property
Limited - styleable elements and pseudo-elements, but limited in
some way
Fully Styleable - Developers can opt into standardized parts and
structure and base styles that are fully restyleable
Fully Extensible - standardization of a control's anatomy, states,
behaviors, allowing re-using controller code via defined parts
]
gregwhitworth: What are you bringing and which bucket does it fall
into?
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 we 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.
gregwhitworth: Imagine within a base style sheet that's
standardized, could look like this
gregwhitworth: achieves similar appearance
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 button 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 parts of the shadow DOM must be labeled 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 accessibility 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 control 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 control
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 ultimately 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
device, this is what's the best from user research
gregwhitworth: Maybe there's a 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-elements, 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 basically 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>
Problem Discussion
------------------
Scribe: TabAtkins
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 think it'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 don't
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
<bkardell> one of the main problems is that it is very hard to do so
and most of them get really important things wrong trying
to fix something rather small
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 overall the same set
of components
nicole: So for me it seems like a *really clear* cowpath to pave
<gregwhitworth> fyi - I'm adjusting the proposal based on feedback
as we don't want to imply webdevs building them is
bad, but we should help remove the need
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 don't think it's a problem that authors 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
something 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 build
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
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 stated most of what I wanted, and Una. The primitives
are lacking.
jcraig: One thing to add, the problem is that with the exception of
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 don't think of recreating the entire thing
jan: Devs need a way to do this alteration in a proportionate-cost
way
<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: Agree with a lot of this, and the way the problem is written
now.
Kaelig: The platform doesn't allow people 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
<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
<fantasai> +1 bkardell
miriam: I'm currently living Nicole's 5y-ago experience
miriam: There's different layers of needing to rebuild.
miriam: There are times I need the full extensibility, but often I
need various steps in between
miriam: So important to me as a dev is being able to adjust only
what I need to adjust, not having a control that is either
"no styling" vs "rebuild everything"
TabAtkins: ...
TabAtkins: It's really important to understand how far browsers
relying on OS-level controls are willing to go
TabAtkins: If we make problems that are only solveable by custom
controls, can only solve problems solveable by Chrome
today
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 in
a bit
proposed resolution: Web developers needing to re-create a browser's
form controls is a problem.
RESOLVED: Web developers needing to re-create a browser's form
controls is a problem.
Definitions
-----------
gregwhitworth: Definition of a control-
gregwhitworth: taken from openui
gregwhitworth: No normative definition
[on slide] A control is a type of component that manages user
interaction. The control has controller code that manages
changes in the component's state and its model based on user
interaction with its parts.
hober: The high-level definition seems fine.
hober: The word "component" has a lot of very specific meanings on
the web
hober: Might be good to avoid using this word to avoid confusion
gregwhitworth: Would it be worth defining a component?
<JonathanNeal> suggestion for the name: widget
<TabAtkins> Agree with hober, btw, "component" is an overloaded word
already
nicole: I don't 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.
<bkardell> widget is used in html and aria
nicole: Like twitter widget, or commenting widget.
<levithomason> Agree with Nicole on "widget" definition not suitable
to this case
nicole: I think generally speaking, people use "component" and
"control" interoperably
<BoCupp> A control is an *element* that manages user interaction?
<melanierichards> +1, element seems sufficient
<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?
<jensimmons> from a thesaurus: part, element, ingredient,
constituent, fundamental, unit, factor
<TabAtkins> Just making it clear: the problem here is the conflict
with "web component"
<TabAtkins> Which is already an existing concept that means
something specific.
<astearns> perhaps a 'design component' then?
levithomason: Greg, on this definition, does this exclude button?
gregwhitworth: No, I'd expect this to include a button
gregwhitworth: A button takes in user interaction.
gregwhitworth: So a button is a control
levithomason: So does that mean a component doesn't necessarily
manage the state? Unless CSS pseudo classes 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 though?
<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.
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
definition of component more important
<boazsender> a control manages user interaction, including changes
in states and data
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 definition, would be
helpful to use the same terms to hook into a11y
hober: Consistency with ARIA sounds good
<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).
<fantasai> proposes s/component/thing and let's move on
<fantasai> file a follow-up issue for bikeshedding
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 definition for this
Francis_Storr: Linked it
<Francis_Storr> w3.org/TR/WCAG21/#definition-user-interface-components
<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.
<levithomason> Above based on feedback so far.
nicole: I wanted to speak to matching ARIA definitions
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
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 the patterns. Instead, the patterns live in
design systems, so we should look more to that for naming
<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!
msumner: 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
<nicole> +1 to UI components
<levithomason> Agree fully on following design systems. These are
the things that define the web.
<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 melanierichards 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.
<bkardell> UI Component* (to be potentially bikeshed later)
astearns: I'm seeing enthusiasm for "UI component". Could resolve to
take that for now, and open a bikeshedding issue.
<levithomason> Agree on moving on.
<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
hober: Going back to Jen's comment, we should have this convo
elsewhere, it might take longer than we have here.
hober: What part of resolving on this definition is required for the
rest of the conversation?
<gregwhitworth> I can re-open this one:
https://github.com/WICG/open-ui/issues/81
<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/#definition-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 definition 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.
<gregwhitworth> Ok, added the comment of the updated proposal here:
https://github.com/WICG/open-ui/issues/81
<br until=":05 after the hour">
<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
Received on Saturday, 17 October 2020 15:01:25 UTC