[CSSWG] Minutes Open UI + CSSWG Joint Meeting 2020-10-12 Part I: Font picker control, Holistic approach to control/component standardization

=========================================
  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:27 UTC