- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 9 Nov 2024 10:17:56 -0500
- To: www-style@w3.org, public-open-ui@w3.org, pastithas@google.com
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
OpenUI-WHATWG/HTML-CSSWG Meeting
================================
CSS UI
------
- The group began the discussion of proposed properties for the UA
stylesheet (Issue #10857: UA stylesheet for appearance:base
<select>) with padding:0.25em.
- The group liked having the value in em, though there wasn't
clear consensus if 0.25em was right.
- It was stressed that in creating this we should keep in mind
good accessibility and user expectations and not be tied to
existing behavior.
- It's also likely authors will overwrite this, so keeping it
lightweight.
- The styling depends on content which is a new pattern and may
require thought to the naming to avoid author confusion.
- The group discussed using currentColor vs system color for the
picker in issue #10909 (Colors to use for appearance:base
`<select>`)
- The group tried to figure out what would be the most expected
for developers and the most minimal since they expect it to
be overwritten.
- Right before the call concluded, they also started exploring
how to ensure that there is appropriate contrast.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/whatwg/html/issues/10730
Present:
Joey Arhar
David Baron
Keith Cirkel
Emilio Cobos Álvarez
Elika Etemad
Chris Harrelson
Mason Freed
Tim Nguyen
Cassondra Roberts
Jen Simmons
Alan Stearns
Anne van Kesteren
Scribe: chrishtr
CSS UI
======
UA stylesheet for appearance:base <select>
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10857
jarhar: Have a list of additional properties proposed for the UA
stylesheet. Think we should just go through them one-by-one.
jarhar: First rule: padding: 0.25em
jarhar: Without this rule, the text in the button would stick to the
borders, this centers it
jarhar: There is a caveat that it changes to 0 if the developer
provides a child button element. That is there because if the
the developer provides it, then we should just use that
button and not add on extra box decoration
emilio: The select has a border right?
jarhar: Going to propose to remove the border actually
jarhar: That way you don't have two borders
jarhar: This was discussed on a separate issue with Tim
fantasai: What is the box model we're trying to style in this case?
What boxes exist and what formatting context does it have?
Is the select a bock box or a flexbox.
jarhar: display:inline-block should answer that question (there is a
proposed UA rule for it)
fantasai: And it directly contains text? and if there is a provided
button it shows the button?
fantasai: There was a discussion about a pseudo elements, where did
that go?
jarhar: We decided not to have a fallback UA pseudo element in this
case, and instead the select element itself should be it
fantasai: If there is a button element, is block layout what you want
for it? don't think so because we want the button to align
with the border right?
jarhar: Yes
jarhar: Think we could do several adjustments if the button is there
<annevk> (display: contents might make focus funky too)
fantasai: from an author's perspective should not see things change
just because you added markup
<masonf> What if we add `select>button {border:0; padding:0}`
instead? And leave select's borders and padding.
<emilio> `select > button { display: contents }`? :)
<fantasai> or maybe select > button { display: contents; }
jensimmons: Interesting that we have styling that depends on content
jensimmons: Don't know of another case that works that way
jensimmons: Not sure if authors would be confused by that or not
jensimmons: For the sake of these conversations more visuals would
be nice
jensimmons: Don't know what to think right now but want to help get
it done, there might be bikeshedding.
jensimmons: can't tell
<masonf> Some common examples and use cases are detailed here:
https://developer.chrome.com/blog/rfc-customizable-select
emilio: Maybe the button shouldn't have decorations and should
delegate that to the select element. display:contents on the
button
emilio: that may be a simpler option that avoids magic
emilio: Also have feedback on the min sizing
emilio: 24px may be too big
emilio: white-space: normal seems find
emilio: 2px block and 1px inline padding already exists?
emilio: Overall, the fewer rules the better
emilio: display:contents could explain has behavior
emilio: Maybe also make it !important
fantasai: Agree display: contents on the button make sense
fantasai: No need for !important
fantasai: considering pixel values for padding, I am in favor of em
because it'll scale with font sizing
fantasai: font-relative is good
<annevk> (.25em seems quite big, that's 4px)
fantasai: not sure why 1.2em, where did that come from?
<dbaron> many of these things are based on the existing UA stylesheet
rules for <select>
emilio: Agree that em paddings are nicer. But also think that if we
can avoid making different appearance:base specific CSS
values that's better. The less differences the better.
emilio: If existing padding is ok then let's try to accept it
astearns: Uncomfortable with having a switch on select content that
is not expressed in the UA stylesheet
astearns: If we have things in the UA style sheet that depends on
some state we should avoid that and fix it
<emilio> `select:has(> button) { ... }` should work
<annevk> Can't it just be `select > button`?
<ntim> I like Elika's suggestion of making button display: contents
<annevk> (I agree with that to an extent, there's definitely things
that are just not worth generalizing to CSS syntax.)
<jensimmons> Totally agree with Alan — secretly putting a switch to
the styles in the engine is even more magical. It can
totally be done in CSS.
keithamus: In favor of the rule as it stands. 24px minimum size is
useful. should consider a11y, and WCAG recommends that
keithamus: I'd prefer even larger but smaller gets quite problematic
<masonf> Rule #3 here says we need to follow WCAG:
https://github.com/w3c/csswg-drafts/issues/10866
<annevk> (E.g., detecting iso-8859-8-i.)
keithamus: 0.25em is also good, a lot of design systems use it
keithamus: Need good defaults for modern-day practices and a11y
practices. This is an opportunity to set good defaults.
<astearns> +1 to not always following current styling
<fantasai> strong +1 to keithamus
keithamus: Should avoid making it too complicated, but since it's
easy for authors to customize it doesn't get in their way
keithamus: display: contents is problematic, might be confusing to
developers. Also might have a11y problems
keithamus: If you have a button in the select then probably the
button should be in the AT, but if it's display:contents
that would mess this up
annevk: One meta point is that as we decide on these rules it'll have
implications for base styles for other controls
annevk: if we decide padding or sizing here then it should make sense
for other controls
annevk: don't want to have to revisit for other form controls
annevk: With regards to display: contents, there are a lot of
implications of display: contents for focus and so on that
make it tricky
annevk: If you just use a child selector then we could override its
border and padding to be 0?
annevk: If you're styling this button will its appearance be?
<emilio> So `select > button { appearance: none; padding: 0; border:
0 }`?
masonf: One rule we're following is to follow WCAG, which is where
24px came from
masonf: Agree that we could have a rule like what Emilio wrote to
remove appearance and put 0 padding and border
jarhar: The way we implemented it is that if the button is present
then focus delegates to it, including focus rings
jarhar: If there is no button then the select element itself gets the
focus
<emilio> display: contents on the button seems like a nicer fix for
the focus issue tbh :)
* fantasai thinks that sounds very confusing for authors to style
masonf: Others said let's inherit padding when possible from
appearance: auto. I think we should fix them to be good.
<annevk> I think if the `button` is being styled in the UA style
sheet we need to figure out `appearance: base` for it.
<astearns> +1 to not making !important rules in the UA stylesheet if
we can avoid it
fantasai: Wanted to agree with Mason's sentiment that we should not
optimize for avoiding rules that override auto, we should
instead make a good and consistent base style without
worrying about auto
fantasai: The button stuff sounds really confusing, since if you have
a button you have to style that and not the select, and if
not the select.
fantasai: The button should be a markup extra that somehow doesn't
need that complication
fantasai: If the purpose of the button is to clarify hierarchies then
limit to that, and make it display: contents !important
emilio: Happy to concede on the padding
emilio: the focus shenanigans: display: contents would be simpler.
then the rules for outlines would be simpler, since you'd
always focus the select and not the button
<fantasai> +1 emilio
keithamus: One thing we might consider is that this is going to get
integrated into sites that already have a lot of CSS,
including around buttons
keithamus: they will also have CSS around focus, active, etc
keithamus: Making the button a transparent part of the select might
be a moot point, because the author is going to have
button styling already in their theme, which they'd have
to undo
masonf: Following on that, if it was a custom element, you'd likely
do the thing where you delegate styling. Feels odd to have
HTML that has a button and the button is not a regular button
masonf: display: contents seems weird from that perspective
<annevk> What's the use case for the custom button? How does display:
contents not invalidate that use case?
<emilio> annevk my understanding is that the button is mostly a way
to be able to slot things in the select
jarhar: Back when we were working on earlier iterations for this
project, there was a way to put anything you want into the
slot. Now that I'm hearing people express concerns about
different ways to handle this button, I'm thinking the
original model was quite nice. Could we go back to that?
jarhar: We can't reuse the slot element, but maybe a new element or
concept?
<jensimmons> No, we should use <button> not a <div> + new slot thing.
annevk: The slot API is a web developer API.
annevk: Don't care about the button element that much, it's the
content?
annevk: Maybe an appearance:base button could help?
ntim: Before thinking about the styles with the button case, want to
step back - what use cases will people use buttons for?
ntim: If it's used for a split button then display: contents is
probably not right
ntim: Would be nice to see a list of use cases
<masonf> Some examples with custom buttons here:
https://developer.chrome.com/blog/rfc-customizable-select
jarhar: The main purpose of the button is to allow the developer to
provide a way to put anything they want in the base element
jarhar: A big use case is declaratively copying the selected option
into the button
jarhar: Without providing them with a button, it precludes them
putting their own or rich content into the in-page select
element part
jarhar: Without doing this we'll miss most use cases
ntim: Does it allow for split buttons?
jarhar: There has been a lot of discussion at OpenUI with experts
jarhar: Split buttons have different a11y mapping, and they recommend
using a completely different element for that, so split
buttons is out of scope at the moment
<fantasai> annevk, see
https://developer.chrome.com/blog/rfc-customizable-select
-- the selectedoption is inside the <button>, and allows
putting in additional content in addition to the
<selectedoption>
<annevk> fantasai, fair. In that case figuring out appearance: base
for button and then unstyling it when it's a child of select
seems like a good way forward to me.
jensimmons: An interesting thing about this project is understanding
what it means to make a UA stylesheet. Definitely think
padding should be font-dependent. But if I we designing a
design system I'd use line height units.
jensimmons: We're trying to fix some decisions made back in the 90s
jensimmons: We're not making the world's best design system though,
just providing a base styling. Might not be the perfect
thing for them, but to find a way to match the new with
the old
jensimmons: without confusing authors
keithamus: To extend on that point, we're not building this for
people who are building on design systems or building a
design system, these are defaults. Design systems will
very likely override most of these.
keithamus: Need to make sure it has accessible defaults, and that the
styles aren't too difficult to override
<ntim> If the only use case is for the button is selectedoption, it
makes sense to me from a styling perspective that button gets
`display: contents`
<fantasai> In that case, wouldn't you just style select { display:
flex; } ?
<keithamus> it might be worth testing it against a bunch of popular
CSS Reset libraries to ensure they don't break it in bad
ways
masonf: Roughly +1 to what Jen and Keith said. Agree authors will
reset it. Minimal is better.
masonf: We've been staring at this screen for an hour, but it's a
quarter of the entire proposed style sheet
masonf: Suggest we iterate in the issue instead of live
astearns: Want to amplify Joey's point that the justification is in
the comment, please reply on the issue
Colors to use for appearance:base `<select>`
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10909
jarhar: Last time we talked about this issue I tried to loop in Tim's
proposed styles for buttons for appearance:base into select
jarhar: Also talked about system colors and contrast, and the picker
jarhar: Since then I've posted some styles that used Tim's proposed
colors for in-page and system colors for picker
jarhar: Thought these would be reasonable defaults
jarhar: Emilio proposed an alternative about system colors
jarhar: I don't have strong opinions but would like to choose
something
jarhar: Emilio liked system colors because it ensures contrast with
all the modes
ntim: My original suggestion of using currentcolor and transparency
was to make in-page controls as easy to style as a blank div
ntim: For the picker, we can't use transparency. Think we should use
system colors there. Dialogs and popovers use them by default
also.
ntim: Everything I've proposed is consistent with other things in HTML
emilio: The main reason why I think system colors could be worth it
is that it works with color scheme and forced colors.
emilio: Also don't think it would be not too hard to do it. But don't
object to using currentcolor etc
masonf: I think we should aim for having a thing that is easiest to
understand, since developers are likely to override anyway.
masonf: Weakly in favor of what Emilio is proposing for that reason
<masonf> In devtools, they'll see that background-color is `color-mix(
in lab, currentColor 10%, transparent)`
<jensimmons> 100% developers do not know that system colors exist.
They will assume these are defined colors in the UA
stylesheet.
fantasai: The currentcolor approach is more minimal I think
fantasai: They get colors either way, but fewer with currentcolor, so
I think it's easier for them to override just that one
jensimmons: There are different groups of colors: text, borders, bits
and pieces
jensimmons: Why are the backgrounds of my form a certain color?
jensimmons: As soon as they change the color of the page it'll show a
difference for their form
jensimmons: Nothing else on the page comes with a background color,
so I think it's better for this to not have one other
jensimmons: Like the idea of a transparent background
jensimmons: It's busywork to have to change that
jensimmons: This makes them feel a pain in the ass to style
keithamus: Dialogs and popovers have canvas as the background color
keithamus: My preference would be system colors
<annevk> I think dialog and popover are different in that they are
displayed in the top layer.
<annevk> Form controls are not.
astearns: I wonder if using transparency would get us into problems
with contrast
emilio: It doesn't necessarily cause contrast issues unless you use
background images
emilio: I think native app design systems do have background colors
on their form controls?
<ntim> material design :)
<jensimmons> Yes, canvas and dialog have backgrounds. That makes
sense. Form controls don't feel special — like they
should be part of the page... they are elements on the
page. Where dialog — well, of course it has a color.
Just like the body itself. It's a thing, that needs a
background.
<jensimmons> What's also super important is thinking through how
authors will override the colors. How will they change
each, and what else does that affect?
fantasai: Is there a precedent for toolkits with transparent
backgrounds?
fantasai: If we go with system colors we'd have to define more of them
fantasai: Different systems also display select elements differently
keithamus: System colors are an abstraction away from color mixing,
but we're presumably sticking to one style
emilio: Nothing prevents us from mixing to currentcolor
fantasai: System colors require contrast, but currrentColor doesn't
know what it is mixing with?
fantasai: Needs contrast between system colors
<fantasai> (can't compute a system color to transparent)
<fantasai> +1 to understanding the developer experience better
Received on Saturday, 9 November 2024 15:18:30 UTC