[CSSWG] Minutes Open UI + CSSWG Joint Meeting 2020-10-12 Part II: Holistic approach to control/component standardization (continued)

=========================================
  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
==========================

Holistic approach to control/component standardization (Continued)
------------------------------------------------------------------

  - Since there are a lot of different author needs, the proposal was
      to have a whole set of solutions allowing authors to do what is
      necessary for their use case.
  - Some of these solutions will be CSS based and some will be HTML
      based, so it was suggested that the OpenUI community group
      create the definition which can be referenced by multiple groups
      and in multiple specs.
  - RESOLVED: Define a spectrum of customizability, have OpenUI define
              these buckets

  - When asked about where there was implementor and author interest,
      there was general consensus that both authors and implementors
      would have interest in the whole spectrum from Hint to Fully
      Extensible.
  - There was doubt that 100% fully extensible would be possible but
      also agreement that 95% would still have a benefit worth working
      towards.
  - One thing to keep in mind going forward it to make sure solutions
      focus on all types of devices, not just desktop.

  - The exact role of the Open UI group will need to be more firmly
      defined. It's currently a community group in W3C but may need to
      change depending on the role it will take.
  - The broad suggestion is that Open UI takes the first pass at
      defining the pieces of a control before passing it off to CSSWG
      and WHATWG to create appropriate properties to interact with
      those parts.
  - An issue on github was opened to refine this further
      ( https://github.com/WICG/open-ui/issues/197 )

===== FULL MINUTES BELOW ======

Agenda: https://github.com/WICG/open-ui/blob/master/meetings/telecon/tpac-openui-csswg-oct-2020.md

Scribe: TabAtkins

Holistic approach to control/component standardization
======================================================

Spectrum of Customization
-------------------------

  gregwhitworth: So next step is spectrum of customization
  gregwhitworth: Jan put it as "varying stages of use-cases we can
                 unlock"
  gregwhitworth: "normatively" 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: Could 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
  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 difference between "fully customizable"
                 and "expose the pieces"?
  jan: It's a question of 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
  <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.
  <astearns> +1 to nicole
  gregwhitworth: That "sub elements" is what I'm hitting on
  gregwhitworth: <select> is a particular type of control, with a
                 meaning
  gregwhitworth: There are sub-pieces to that. You can get those
                 behaviors on their own.
  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.
  <fantasai> +1 to not understanding the "smaller pieces" point, it
             seems important, but not getting what's meant
  <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 aren't mutually exclusive
  melanierichards: Don't want to throw out some of the solutions is
                   because if we only had composable world, we're
                   putting 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 the problems 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

  TabAtkins: Just noting that this whole conversation seems to touch
             on exactly the extensible web manifesto core problem
             statement
  TabAtkins: which is in general we should make the platform have as
             small as reasonable jumps of necessary re-implementing of
             functionality just because you need some small change
  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
  TabAtkins: Right now you can do very minor tweaks, or re-implement
             from scratch
  TabAtkins: Should be able to tweak the parts you need

  fantasai: I think the spectrum 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.
  fantasai: The same conceptual control, should be able to approach it
            in each bucket without having to fall back to "fully
            extensible" each time
  <bkardell> +1
  <miriam> +1
  <una> +1 also!
  fantasai: Unsure what we're aiming for in resolution here, just
            emphasizing that authors are wanting each of these levels,
            and shouldn't be forced into one particular level.

  BoCupp: Greg, could you 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 spectrum
  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 existence of these buckets,
                 agree they should live somewhere, and help drive
                 solutions toward them

  una: Think it's really helpful to differentiate 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
       extensibility is actually required to enable some of these
       "simple" additions
  una: So the entire spectrum 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 extensibility
  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
  <melanierichards> great point boazsender!
  * bkardell agrees
  <tantek> Might also be useful to cluster different form control
           customization use-cases (as explicit use-cases) in these
           buckets.

  astearns: Seems I'm hearing consensus that this is a good way to
            break up the work
  gregwhitworth: So two things
  gregwhitworth: So beginning of spectrum is css-ish, end is html-ish.
                 Think this definition 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
  astearns: So these buckets become evaluation criteria for OpenUI to
            use
  <levithomason> Agree on Open UI as some kind of "rating" or
                 "category" on the research pages. This is perfect for
                 analyzing existing UI components.
  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 are search
                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
  <fantasai> tantek, yeah -- either informative section of a spec or
             in a Note
  <tantek> fantasai, yeah informative section in a spec makes sense,
           not sure we even need something as formal as a Note
  <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

  boazsender: To horizontal review, there are parts of the w3c that do
              that. There's process documentation...
  boazsender: Don't know if those reviewers have areas for notes
  boazsender: What is the 5-year picture for this?
  boazsender: Dunno if w3c has bandwidth for this kind of research; is
              there an idea that this would land in a standards body?
  <bkardell> I think it's fine if that lives in openui
  gregwhitworth: I would expect this to be a page on OpenUI that
                 explains this
  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
  gregwhitworth: And just generally to provide a set of common
                 terminology

  fantasai: I just don't 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 reference
  <fantasai> Like, if we're formally referencing this document from
             one of our specs, it needs to exist 20 years from now
  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)
  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 discussions about 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
  <tantek> I believe the CG can publish "reports", so perhaps that's a
           good way to get the buckets documented

  astearns: So proposed resolution is: define a spectrum of
            customizability, have OpenUI define these buckets
  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 should still be our goal to allow
            customization at every level

  RESOLVED: Define a spectrum of customizability, have OpenUI define
            these buckets

Implementor Interest
--------------------

  gregwhitworth: So based on the problem at the beginning, ultimately
                 not providing webdevs the ability to use what they
                 need and making it as simple as possible, creates
                 end-user implications
  gregwhitworth: Implementor 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 implementors
                 perspective, where on the spectrum they're willing to
                 go
  gregwhitworth: Solely in the A camp, or willing to do Hints (B), or
                 pseudo-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 sure I'm investing my time in those most
                 productive areas
  gregwhitworth: [rephrases what I wrote above]
  gregwhitworth: What I'm trying to understand is, from an impl, to
                 what level are you willing to explore?
  gregwhitworth: Managing expectations, don't 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 questions 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 there's 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 think we 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 shouldn'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.

  scribe: fantasai

  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 in the 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 people 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 certain 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
  whsieh: There's also watches to keep in mind
  <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?
  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 standardize 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
                corporations wants pixel-perfect across platforms

  BoCupp: Statement to answer greg's question
  BoCupp: On the Microsoft 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> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ControlUICustomization/explainer.md
  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 select 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 design 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 unified form factor
  gregwhitworth: ...

  brandonferrua: Just want to provide perspective on Salesforce's
                 problems
  brandonferrua: We fall in the ranges of like C,D, sometimes E
  brandonferrua: I think 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 experience 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: Further end of the spectrum excites me
  heycam: Bunch of work in Open UI, I think this is a cool 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
          the 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 be overridden
  jensimmons: Author has to let go of control
  jensimmons: But on extensibility 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 someone 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 extensibility, 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
  <boazsender> +1 jensimmons
  <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> 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 think about
             how..
  bkardell: I think I agree with most of these things
  bkardell: As it stands today, as much as we're saying people 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 people who will use it
  bkardell: Further we get to the right, getting into use cases where
            extending and taking control
  bkardell: don't know what's the best way to do that
  bkardell: It seems like those ones on the left are obvious "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: Microsoft is interested in full spectrum
  melanierichards: failed to mention, that some of the ? for full
                   extensibility came from explainer shared on IRC
  <gregwhitworth> the explainer is linked at the end of the deck as
                  well
  melanierichards: and developing primitives
  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 considered
                 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 people 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
                 extensibility, in addition to part definitions, will
                 need that for fully extensible
  gregwhitworth: Have to define the parts

Implementor Interest
--------------------

  myles: Questions asked fairly direct, want to provide a direct answer
  myles: It is true that some web developers need flexibility 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
  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
  <bkardell> agree with myles - that's what I was saying too... I
             believe myles said it better

Where to Do the Work
--------------------

  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 that 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?

  Scribe: TabAtkins

  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?
  <bkardell> sorry for going back to the previous topic, it just seems
             a thing you hit on with the 'form' part
  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 can 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: Don't think we have to try today to figure out
  <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?”
  <bkardell> JonathanNeal: that is maybe a possible implication of
             such information, but I wasn't proposing jumping to that
  <JonathanNeal> bkardell: ah, okay. I appreciate the clarification.

  astearns: As the CSSWG co-chair, 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, for properties and states, would be
                 done in OpenUI
  <boazsender> is this process design / working mode documented
               somewhere that we could read it?
  gregwhitworth: Coming back to my proposal, don't want to imply that
                 a spec has to be "complete" before it can be proposed
  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 the process?
  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
  gregwhitworth: We just want to avoid duplication of effort - where
                 we take the proposal to HTML, and then it's all
                 re-litigated and redefined
  gregwhitworth: The composition of the behaviors/states/anatomy
                 should be defined in OpenUI
  gregwhitworth: So like for details/summary, those elements should be
                 in HTML, but the behaviors/states should be in OpenUI.

  <boazsender> I don't think it is gate keeping to be clear on what
               the process design is.
  <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 should 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
  BoCupp: I don't think it's gatekeeping to centralize expertise
  BoCupp: Would love to get the process written down, would volunteer
          to help
  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, because 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 the process, 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 should 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 figure out 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 don't want to litigate
         it now, but I want it to be written down at some point.
  boazsender: Issue #197 open to deal with that
  <astearns> https://github.com/WICG/open-ui/issues/197

  boazsender: More things to consider including
  boazsender: Not just where it ends up, but things like test writing
              and docs
  <gregwhitworth> yeah test authoring is a desire
  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 behavior.
  jan: Three is a retroactive identification of existing elements,
       their construction/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 definition 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 figure 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 of 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 where the 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.
  <nicole> That's part of what w3c is for, right? Everyone has signed
           to share IP?
  <TabAtkins> nicole, I think she meant more in the general sense, not
              legal sense

  Kaelig: Curious about next steps, as someone following but wants to
          be more involved
  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
  <melanierichards> this was a fantastic conversation everyone, thank
                    you
  gregwhitworth: I'll follow up in future meetings to make sure
                 CSS/HTML/etc people are looped in properly

  levithomason: Seems like there were questions about 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 the creativity 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 collaboration from
                anyone with expertise
  levithomason: Regardless of whether they're in a standards body, or
                author, etc.
  gregwhitworth: I'll follow up offline any remaining issues, might
                 have Friday overflow for additional topics

Received on Saturday, 17 October 2020 15:01:41 UTC