- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 17 Oct 2020 11:00:55 -0400
- To: www-style@w3.org
- Cc: public-open-ui@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Joint Meeting with Open UI
==========================
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