- From: Dael Jackson <daelcss@gmail.com>
- Date: Sun, 16 Aug 2020 07:53:57 -0400
- To: www-style@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.
=========================================
CSS Inline
----------
- There was no strong contender to rename inline-sizing (Issue
#5189: inline-sizing is too similar to inline-size), but a long
list of options. People are asked to review and think through
what's the best name.
Open UI Presentation
--------------------
- gregwhitworth presented the current status of the Open UI
community group. The slides are available here:
https://lists.w3.org/Archives/Public/www-archive/2020Aug/att-0001/Open_UI_Overview.pdf
- A lot of research has been done into the problems web developers
face with form controls, why they feel the solution isn't
sufficient, and if there is demand for a better solution.
- There is a lot of desire to be able to have form controls where
the developer can control some level of presentation but not
have to rebuild from scratch.
- The hardest to do elements, especially select, are also the most
requested.
- Work will continue but the group was very excited by the
possibilities this would open and grateful for the presentation.
Selectors
---------
- RESOLVED: Rename to ::file-selector-button [from
::file-chooser-button] (Issue #5049: Can you standardize
a pseudo-element selector for file inputs?)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-summer-2020#thursday
Present:
Rachel Andrew, Fronteers
Adam Argyle, Google
Rossen Atanassov, Microsoft
Tab Atkins-Bittner, Google
Christian Biesinger, Google
Mike Bremford, BFO
Oriol Brufau, Igalia
Tantek Çelik, Mozilla
Elika J. Etemad, Invited Expert
Simon Fraser, Apple
Megan Gardner, Apple
Daniel Holbert, Mozilla
Jonathan Kew
Una Kravets, Google
Chris Lilley, W3C
Peter Linss, Invited Expert
Alison Maher, Microsoft
Myles Maxfield, Apple
Nigel Megitt, BBC, and Chair TTWG
Tess O'Connor, Apple
Melanie Richards, Microsoft
Florian Rivoal, Invited Expert
Devin Rousso, Apple
Jen Simmons, Apple
Sam Sneddon, Apple
Alan Stearns, Adobe
Greg Whitworth, Salesforce
Scribe: TabAtkins
CSS Inline
==========
inline-sizing is too similar to inline-size
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5189
nigel: Semantics of the feature aren't in question, but name is.
nigel: Many proposals that people have added to the thread
nigel: A bit of side topic - if you think about the problem
differently, this is about extending the background area in
the inline direction, at the end of each line, so the text
isn't up against the edge of the bg, often used in captions
florian: I think we're confusing two features here.
florian: line-padding is still called line-padding and is in Text 4.
florian: This is a different feature. Hence its name is confusing,
since it confused you about it. ^_^
nigel: Ah right, so this is more about expending the size in the
block direction
nigel: But line-padding did come up as a similar topic in the
thread, as a possible direction to think about things
together.
nigel: Not sure they should be, they seem distinct to me
Rossen: So I see line-fit, inline-fit, inline-area
Rossen: Then a long list from twitter
<Rossen> box-decoration-fill, line-height-sizing,
inline-background-painting, inline-logical-height-sizing,
line-stretch or inline-stretch,
inline-cross-direction-sizing, inline-fill-type,
inline-box-sizing, line-sizing, vertical-sizing-rule,
line-fill or line-fit
TabAtkins: suggest we avoid the word inline
florian: That's also the trick, it's not about "the line". It's
about the block direction of inlines.
TabAtkins: Right, I just meant "line" was okay re: my objection.
faceless2: This feels similar to leading, could use that in the name.
Rossen: Do we have other terms of art we could try to borrow?
astearns: 'leading' seems fair game in this
fantasai: It's not about leading - it doesn't affect layout.
fantasai: It just changes the size of the background/border area of
inline boxes, in the block direction.
fantasai: Other thing to consider is possible future directions for
this property.
fantasai: So ultimately it's about the height of the inline box
fantasai: So we might want to change *how* we fit around text,
and add options for that.
fantasai: Right now it's just "fit the text" or "fit the line".
Rossen: Is layout not in scope for this property, then?
florian: inline-paint-height?
Rossen: inline-background-extent?
fantasai: It affects all the box edges, in terms of where they
apply graphically.
<fantasai> https://github.com/w3c/csswg-drafts/issues/5189#issuecomment-661268373
fantasai: Amelia created some nice illustrations
florian: I think "inline-*-extent" would have the same confusion
fantasai: I liked inline-fit because it does describe how it
actually works. So like "inline-fit" or "line-fit" or
something else?
<TabAtkins> inline-block-fit
<fantasai> it doesn't apply to inline blocks
<TabAtkins> i know, it's the block axis of inline elements ^_^
<fantasai> it also affects borders
<astearns> text-background-fit?
florian: At some point Amelia proposed box-decoration-*, I assume
we're not doing that?
fantasai: That implies more general. It's super long for one.
florian: inline-box-decoration-height? A mouthful...
nigel: inline-box-height?
Rossen: That'll excite people - it says layout to me.
faceless2: *-shape, we kinda use that elsewhere?
Rossen: Shape implies geometry, not just size.
fantasai: I feel like this is something we come back to during a
break, after people have some time to think about it.
<tantek> +1 come back to it during a break
<fantasai> inline-box-fit?
Rossen: Sounds good, we got awareness on the issue.
Rossen: So we'll continue discussion during the break.
<dholbert> maybe "decoration" is fine after all; it was making me
think "text-decoration", but now I'm remembering we have
box-decoration-break etc. as well
Open UI presentation
====================
github: https://github.com/w3c/csswg-drafts/issues/5350
<gregwhitworth> Here's the link to the slide deck:
https://1drv.ms/p/s!AhG1j1eK4stagbq0NDph3XtbFPPKokY
[greg presents]
gregwhitworth: I met with ARIAWG 3 weeks ago about this; after last
weeks' discussion about accent-color, and previous
about file-input button, I thought it would be good
to go over the Open UI CG and what it's doing.
gregwhitworth: Hopefully leave time for discussion/comments/etc
after.
gregwhitworth: Edge and Chrome worked to update their form controls
in Chromium to update a11y, touch, and a visual
refresh.
gregwhitworth: Gave talks about this with Nicole Sullivan, the
Chrome half of things.
gregwhitworth: Here's high-contrast working, for example.
[shows slide of some widgets in high-contrast mode]
gregwhitworth: Lot of people when we show them get excited we've
spent time on the built-ins.
gregwhitworth: A common question afterwards is "how come when I'm
navigating the web I don't see these controls?"
gregwhitworth: Lot of reasons, onion-peeling things.
gregwhitworth: Did a lot of surveys.
gregwhitworth: Wanted to understand why webdevs recreate form
controls.
gregwhitworth: 37% is changing the appearance, 32% is more
functionality, 27% is browser inconsistency, 3% is
a11y, 2% is other
gregwhitworth: These are consistent answers.
gregwhitworth: There are low-hanging fruit in each category, we think
gregwhitworth: A big consistent one is browser inconsistencies.
gregwhitworth: Like Chromium's color input
gregwhitworth: The site would say "what's the lowest common
denominator"
gregwhitworth: Chromium historically is the native Windows color
widget, which is real old-school and W95-looking. And
if it didn't give them what they needed, they'd throw
it away and do their own.
gregwhitworth: So if there isn't interop, it doesn't matter what we
ultimately introduce across browsers.
gregwhitworth: So if we can't standardize across many respects, the
rest of the work is fruitless. So that's a big reason
Open UI came into existence.
gregwhitworth: The top 10 list of recreated form controls
gregwhitworth: select, checkbox, date, radio, file, progress,
button, dialog, textarea, text
gregwhitworth: Workhorses of the web
gregwhitworth: button/textarea/text are near the end, as they're
less problematic in general
gregwhitworth: And more importantly, we asked which is most
frustrating, and select beats everything by a *lot*
[ 42.7% select, 17.3% date, 9.3% file, 8.0% checkbox, 6.7% radio,
4.0% range, < 3% the rest ]
gregwhitworth: You see complex ones at the forefront; simpler ones
seem less frustrating.
gregwhitworth: I think it's become so status quo that this problem
is part of the web
gregwhitworth: So people come up and say "should the platform even
invest in this?"
gregwhitworth: I often hear there's a bunch of component libraries,
the big sites have big teams focusing on the same
stuff browser devs do, so all these fundamentals
aren't gaps on those top sites.
gregwhitworth: We looked at a bunch of menu/popup libraries. Spent
30min, found *numerous* a11y problems, can't use in
keyboard, etc
gregwhitworth: This is 8 months old, hopefully a little better today.
gregwhitworth: I tested high-contrast but didn't show here; due to
the checkbox/radio hackarounds, high-contrast would
often make the entire form disappear. That's extra
concerning.
gregwhitworth: In addition to this, I spoke with partners, major
sites, component libs, ssg, pretty much everybody I
could
gregwhitworth: All of them had no desire to rebuild these things.
gregwhitworth: My favorite quote is us asking "would you leverage
these if the platform gave better ones, or would you
keep using your own?" and someone's VP said "yes,
dropdowns aren't our product"
gregwhitworth: Another project, I was talking to the component
engineer leading the dropdown, and they pinged me
asking for select behind a flag, because they want to
stop owning that component; it's just always buggy
and annoying.
gregwhitworth: So there's obviously a hunger and desire for better
natives.
gregwhitworth: So this is an opportunity for us.
gregwhitworth: Don't want to pretend this is new. Rossen, when we
worked together, emphasized this has been tried many
times before.
gregwhitworth: The way I tried to frame this is...
gregwhitworth: A designer builds out a new control design.
gregwhitworth: Recall the earlier problem zones, the spot that
people spend the most time on is often a11y
gregwhitworth: And then ultimately we make a spec.
gregwhitworth: Literally everyone is doing this, including browsers
and OSes.
gregwhitworth: I got OS devs saying "yeah, this is web-specific, but
it overlaps a ton with our designs as well"
gregwhitworth: So I view Open UI as very similar to how we entered
Chromium.
gregwhitworth: We started exposing certain parts for certain things,
we saw devs start adopting.
gregwhitworth: But we haven't yet taken a step back and started
holistically talking about controls in general.
gregwhitworth: There is not a desire to lock things in place to
stifle innovation in UI, but we do want to pave
cowpaths as possible.
gregwhitworth: And would like there to be a single source of truth
for like "what makes a select"
gregwhitworth: Linked at the end here is a massive explainer
gregwhitworth: We started with the select, but realized quickly we
were actually defining a more general term, which is
"what is a control?"
gregwhitworth: It was pointed out that controls follow an MVC model
gregwhitworth: As you manipulate the input, the model changes and
influences the view.
gregwhitworth: So we want Open UI to define the model and the
controller, without defining the view.
gregwhitworth: So I tried to take the whole explainer and scrunch it
down here
gregwhitworth: [reads the slide]
[
Control: a type of component that allows some form of user
interaction. The control has controller code that managers the
transition of the component's states and the model based on end
user interaction with defined parts.
]
gregwhitworth: So a quick thought exercise
gregwhitworth: Everyone envision a select
gregwhitworth: What does it look like, what are the behaviors
gregwhitworth: [shows W95 screenshot]
gregwhitworth: I wonder if anyone had this in their head
[shows very old Apple UI - Mac OS 7.0]
gregwhitworth: No scrollbar, but a checkbox, and some colors next to
the options. Actually can't even do this on Web
platform today
[shows a more modern filtering UI from a webpage]
gregwhitworth: You could imagine this being a composite control as
well, being an type=search actually that just has the
behavior
[shows a contact selector]
gregwhitworth: Or maybe like this, showing off select limitations
today. This uses a grid to show the pictures, name,
and title.
gregwhitworth: But ultimately it's just a select underneath
everything, giving some values.
[shows old iOS "roller" select]
gregwhitworth: Emphasize again that the model and behaviors aren't
changing, but controller does a little - scroll
events are scrolling this, but site might want to
take over.
gregwhitworth: So wanted to break down the anatomy of the inputs
gregwhitworth: If there's standard terminology on the web already,
we use that
[shows off a select's anatomy]
gregwhitworth: A particular bit of controversy here is whether the
"top" part of a select is a button (as currently
noted) or a textbox, given how many UI frameworks
already give type-in
gregwhitworth: This ties into the accent color from last week, can't
define it without knowing where it'll be applied
gregwhitworth: Then once you have the parts, you can define how
events transition between parts.
<astearns> some selects highlight the portion of each option that
the typeahead is matching on, which I like
gregwhitworth: Based on research across component libraries,
figuring out if it was nailed down due to user
research, or accidental, or if it needs to be
standardized at all, etc
gregwhitworth: What we want overall is to obviate the need for
authors to go to WAI-ARIA's big list of conditions
gregwhitworth: Complicated mapping of a11y conditions back to your
control
gregwhitworth: And since so much of the issue is just "I want to
make slight cosmetic tweak", but they have to
reinvent all the rest themselves
gregwhitworth: We find that if you provide the core functionality,
with type-ahead searching, almost nobody actually
wants more functionality at that point. They just
want cosmetic control.
gregwhitworth: Another part of the explainer is the part=""
attribute, giving it meaning in the control itself.
gregwhitworth: So we've exposed that there are actual slots and
parts in our Open UI components.
[shows off a custom select's HTML code]
gregwhitworth: Note here, on the "button" container, I want to
replace that top part with my own UI, but let the
rest of the control code work as normal.
gregwhitworth: So by noting the part="", the component just grabs
that, and otherwise hooks up everything as it would
with its own button.
gregwhitworth: So this becomes powerful - so long as the element is
child of the select, the select can give it meaning
and behavior.
gregwhitworth: Then the controller comes along, adds in appropriate
ARIA, tabindex, listeners, etc.
gregwhitworth: So I feel like people are often "that sounds cool in
theory", but we've gone and built a WC that follows
this model.
gregwhitworth: Not done yet.
[shows off control]
gregwhitworth: When I hit spacebar we move to the options, I can
arrow and hit Enter and it selects that one.
gregwhitworth: Here's a Bootstrap example; the text of the select
option doesn't bring up the popup, but the arrow does.
gregwhitworth: And here's a more extreme radial design, that still
works exactly per normal select interactions
gregwhitworth: And here's a typeahead select, giving minimal
customization and hooking into the underlying search
mechanics.
<tantek> great presentation gregwhitworth
Rossen: I applaud you for not stopping on this journey
tantek: I tried to work on this 20 years ago, greatly sympathize,
great work.
tantek: For select, one common thing I saw in your examples is the
button and list being different widths
tantek: Having two [unrelated] things in CSS match their
shrink-to-fit width is, hm, hard or impossible?
gregwhitworth: Because they're just block-level siblings, you can
use grid to make them the same width if you want
gregwhitworth: This select is no longer a separate window - we can't
do that without security issues.
fantasai: I know that select dropdowns have special behavior when
natively implemented, to avoid falling off the edge of the
screen. Does this mean if I style my select, I need to
re-implement that?
gregwhitworth: Expect us to come with proposals for exactly that. I
don't expect you to re-implement, we should make it
easy to add in.
<tantek> that seems like a new layout / positioning feature
fantasai: Looks like you're looking at how to build UI from scratch
- have you looked at how to take existing markup and make
it more stylable, so people don't need to bring their own?
<tantek> +1 fantasai - we want to solve *both*
gregwhitworth: My one hesitance is, say, take checkbox. If we don't
allow replacements, but let you change color of the
glyph - people quickly start asking for animation, or
adding a label, etc.
gregwhitworth: Gets more complex really quickly.
fantasai: Not saying to stop there, but we should go in from both
sides, so we can minimize the number of people that need
to rebuilt their control.
fantasai: While also making it possible for people rebuilding their
components to make it easy.
Rossen: Last time, in Toronto, we decided not to use CSS to expose
or define parts.
<TabAtkins> That's not a relevant address to fantasai's concern -
she's not talking about defining parts in CSS.
tantek: Strong agree to also let people fix native markup.
<br dur=15min>
<gregwhitworth> hey folks, if you want to be a part of the meta Open
UI + CSSWG collaboration I've setup a doodle poll
for mid-August to try and drive clarity:
https://doodle.com/poll/y7kvmqfdggf6abzh
CSS Selectors
=============
scribe: fantasai
Can you standardize a pseudo-element selector for file inputs?
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5049#issuecomment-639161484
emilio: We came up with name "file-chooser-button-thing"
emilio: OpenUI folks debated came up with different name
emilio: I feel like we should still get a CSSWG resolution
Rossen: So this is renaming ::file-chooser-button
emilio: Yes
emilio: Proposal is ::file-selector-button
gregwhitworth: That name is from looking through various components
gregwhitworth: Most don't have a button, but of the ones that do,
that's the naming trend
<fantasai> wfm
<astearns> +1 from me
florian: Sounds good to align with OpenUI
florian: Second thought is how to coordinate better with OpenUI
Rossen: We have plenty of liaison here in the WG
Rossen: The meta-question here, we can debate later
Rossen: Ideally most such work can involve WG members and the WG
Rossen: See mostly support, no counterproposals. Any objections?
RESOLVED: Rename to ::file-selector-button
Received on Sunday, 16 August 2020 11:54:50 UTC