- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 22 Nov 2024 18:02:43 -0500
- 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 UI
------
- RESOLVED: Name the pseudo-element ::checkmark (Issue #10908:
Pseudo-elements for checkmark and dropdown icon for
appearance:base `<select>`)
- RESOLVED: Go with ::picker-icon (Issue #10908)
CSS View Transitions
--------------------
- noamr introduced the proposal to remove 'auto' (Issue #10995: Allow
an auto-generated `view-transition-name` that doesn't default to
ID). There were objections to the removal so discussion will
return to github.
CSS Color Adjust
----------------
- RESOLVED: Close no change (Issue #11097: Should forced-colors
support `color-mix()`?)
CSS Conditional
---------------
- RESOLVED: Rename "overflowing" to "scrollable" (Issue #11182:
scroll-state(overflowing) is confusing because it ignores
clipped overflowing content)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Nov/0018.html
Present:
Jake Archibald
Adam Argyle
Tab Atkins-Bittner
Kevin Babbitt
David Baron
Oriol Brufau
Stephen Chenney
Emilio Cobos Álvarez
Yehonatan Daniv
Stephanie Eckles
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Chris Harrelson
Jonathan Kew
Roman Komarov
Vladimir Levin
Rune Lillesveen
Chris Lilley
Florian Rivoal
Cassondra Roberts
Noam Rosenthal
Miriam Suzanne
Alan Stearns
Josh Tumath
Bramus Van Damme
Lea Verou
Scribe: TabAtkins
CSS UI
======
Pseudo-elements for checkmark and dropdown icon for appearance:base
`<select>`
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10908#issuecomment-2455470313
fantasai: Just 2-3 straw polls
fantasai: We've been discussing the pseudos for parts of form controls
fantasai: First is the pseudo that represents the checkmark in form
controls. check in checkbox, dot in radio button, indicator
in select
fantasai: The checkmark pseudo is always there, it's just not visible
when not checked
fantasai: so you can style it to an x when unchecked, etc, because
it's still there, you just have to style it visible
fantasai: So the options are ::checked and ::checkmark
<jarhar> ::check and ::checkmark
<JakeA> Checkbox contains a check, so `::check`
<JakeA> I'm also fine with ::checkmark fwiw
<TabAtkins> it contains a check mark in my idiolect ^_^
<TabAtkins> (but I'm good with ::check)
<fantasai> :checked pseudo-class also exists
<fantasai> input[type=checkbox]:checked::check?mark? { style; }
<jarhar> option::check(mark)
<schenney> +1 to :checkmark, as this is the thing that is being
drawn, not the verb "to check".
<argyle> ::checkmark
<fantasai> POLL: A) ::check B) ::checkmark
lea: What is the pseudo on in a <select>? the <select> or the
<option>?
fantasai: The <option>
lea: Have we considered ::marker?
<jarhar> ::marker has been avoided in several conversations due to
property limitations and other baggage
fantasai: That's used for list-items already
JakeA: The idea is that we'd use this as the base rendering of a
checkbox input?
lea: Have we considered anything that doesn't imply a particular
rendering?
lea: This implies it'll always look like a checkmark
fantasai: we could call it a checked-mark
<fantasai> ::checkedmark
<fantasai> :checked
<jfkthame> ::indicator ?
TabAtkins: Since the pseudo-class is already :checked, I don't have a
big problem with the name possible being
non-representative of the actual appearance
<lea> +1 for ::indicator
fantasai: I'm still going with the two options unless someone has a
strong feeling
<fantasai> I object to ::indicator because it is too generic
fantasai: "indicator" is super generic, a million things could be an
indicator. This is specifically about the mark on form
elements that can be checked
lea: I agree indicator is too generic, marker is about for
list-items, check/checkmark are too specific... I dunno
JakeA: Since :checked is the pseudo-class, does that sway you at all?
I agree with you, but I think that pushes me to support ::check
<argyle> `:checked::checkmark` vs `:checked::check`
lea: If anything, :checked indicates we need something more generic,
:checked::check is funky
fantasai: We have a lot of pseudos that are specific to form
elements, they won't be reused. Discussion of what this
pseudo *is* should be another issue
<noamr> I thought this is time-boxed to straw polls. This discussion
doesn't seem like either time-boxed or a straw poll
<masonf> Straw poll could be 1) ::check, 2) ::checkmark, or 3)
something else?
astearns: trying to timebox, I think we should go with Mason's
strawpoll.
<lea> 3
<schenney> (2)), because I agree that almost any other word like
indicator or active, or selected is overloaded.
<florian> 1
<bramus> 2
<kbabbitt> 2
<astearns> 2
<jfkthame> 2
<TabAtkins> 1, 2
<noamr> 2
<stepheckles> 2
<argyle> 2
<kizu> 2
<dbaron> 2
<masonf> 2
<joshtumath> 1 or 2
<fantasai> 2, 1
<futhark> 2
<jarhar> 2
<chrishtr> 2
<JakeA> 2
<florian> 1 preferred, 2 ok
astearns: 2 is obviously the winner
astearns: proposed resolution is ::checkmark
RESOLVED: Name the pseudo-element ::checkmark
fantasai: Next is the dropdown arrow on select. Proposal is to use
the same pseudo for that and other pop-up controls (like
date picker, time picker)
fantasai: "this is the thing that indicates you can trigger a popup"
fantasai: For some form control that's the only targetable area,
other form controls can cause it in a larger area
fantasai: Current thinking is a single pseudo representing an icon
that can be clicked to open things
<fantasai> https://github.com/w3c/csswg-drafts/issues/10908#issuecomment-2455470313
fantasai: Long list of things that have been proposed
<schenney> expander
<jarhar> I like ::picker-icon
JakeA: I don't like the ones that suggest it's the thing you click on
to open it
<TabAtkins> like ::picker-opener, etc
JakeA: If it's just referring to that little arrow...
<masonf> +1 to that logic: it's just the "icon", and it *might* be
inside a button.
argyle: Do we have a list of affected elements?
argyle: we have ::picker(), can we involve that? ::picker-picker?
<masonf> Pickers are (typically): select, input text with datalist,
color picker, date/time picker
fantasai: This is on the form element, select::bikeshed
argyle: And details summary? same or different?
fantasai: Totally separate
lea: The current use-case - is this always an arrow in every
platform? or other displays?
fantasai: The icon will probably differ between form controls
fantasai: but the current proposal is appearance:base, it'll probably
be a disclosure triangle of some kind
fantasai: author would be able to change it
<masonf> But on a date picker, it's usually a calendar icon
lea: Yeah, just asking about default styling, any case where this
isn't an arrow/caret?
fantasai: We might have seen a + sign before?
<lea> I quite like `::opener`. `::expander` could also work.
`::picker-opener` is too long
<fantasai> lea, the reason for the ::picker- prefix is to tie it to
the ::picker() pseudo-element which it opens
<fantasai> or indicates opening
<argyle> will this always invoke a picker? or can it also expand
inline?
dbaron: If we're gonna do something here we reuse for date pickers,
there are some differences
dbaron: Like how Jake mentioned, how the entire control is clickable
in <select> isn't always true in date pickers, the popup is
separate from the individual bits with other controls
dbaron: Don't think there's necessarily a hard requirement that this
is or isn't the same thing we use on date picker
schenney: In this discussion people keep saying "icon", think this
strongly argues for icon
<masonf> It's a down-arrow icon on select and color, and a calendar
icon on the date picker. So always an "icon".
lea: "icon" could be decorative
<TabAtkins> ::picker-icon
<TabAtkins> sounds reasonable to me
<joshtumath> +1
argyle: "search" has several icons, one for datalist, one for clearing
<JakeA> +1 for `::picker-icon`
<lea> I would rather name it after its purpose, rather than a
specific rendering
argyle: inputs that have a list become picker-invokers also
<dbaron> `::picker-icon` was one of the 2 most popular options in the
prior poll referenced in jarhar's comment
masonf: In search, the icon doesn't open a picker, it does something
else
argyle: So I imagine if I did ::icon in a search, I'd expect it to
select both? ::picker-icon is clearly about the picker, makes
sense
argyle: Do we need to separate "picker button" from "picker icon"?
one wrap the icon, can be styled, etc; the other is the
content
TabAtkins: You would use 'content' to insert a string or whatever
<lea> `::picker-trigger`? `::picker-invoker`? `::picker-opener`?
They're long, but not that much longer than `::picker-icon`
<dbaron> masonf: for search, `::clear-icon` for the one that clears
astearns: So main difference between the first item on the popular
list (picker-icon) and the next three is the rendering vs
what it does
astearns: Want to go into some reasoning?
fantasai: In some controls, the icon is the only clickable thing. In
others it's an indicator, but you can click in multiple
places. Varies between controls, and has varied over time.
astearns: Suggest poll between icon and action?
fantasai: Suggest everyone put their favorite, we take the top few
lea: I like Alan's suggestion. don't feel strongly about the name,
but do feel strongly about it describing the action
<masonf> +1 to just jumping to names
fantasai: Unsure the grouping is reasonable. could collect into two
sets...?
<dbaron> (I'm not sure if "button" is purpose or rendering...)
<lea> dbaron, I would think purpose. `::picker-button` seems better
than icon as well
astearns: I'm convinced by David's statement that my categorization
isn't correct.
astearns: Let's straw-poll on the first four options.
astearns: 1) ::picker-icon 2) ::picker-button 3) ::picker-opener
4) ::picker-trigger
<argyle> 1
<fantasai> 1
<masonf> 1
<schenney> 1
<TabAtkins> 1
<stepheckles> 1
<kbabbitt> 1
<noamr> 1
<jarhar> 1
<astearns> 1
<ydaniv> 1
<dbaron> 1
<JakeA> 1
<bramus> 1
<futhark> 1
<florian> 1
<JakeA> Because it's iconography within the picker/opener/trigger
<joshtumath> 1
<oriol> abstain
<lea> anything other than 1
<ChrisL> 1
<flackr> 1
astearns: Straw poll seems clear. Let's resolve on picker-icon.
Objections?
RESOLVED: Go with ::picker-icon
astearns: Third straw poll?
fantasai: That's it
CSS View Transitions
====================
Allow an auto-generated `view-transition-name` that doesn't default
to ID
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10995#issuecomment-2471478451
noamr: There was a resolution previously for the behavior of "auto"
noamr: where it goes to the ID as a name, then falls back to
element-identity
noamr: Jake raised some good points
noamr: myself and a few other googlers consulted as well
noamr: We feel like there's no current good proposal for "auto".
We're not against doing something with the word "auto" in the
future, but we're not suggesting anything else for "auto"
right now.
noamr: So our suggestion is to remove "auto" from the spec for now.
Leave "match-element"
noamr: Then get community feedback, and perhaps redo auto in the
future
noamr: we'll keep "auto" as an invalid name, so we can use it in the
future
fantasai: Our position is we think the current definition provides a
useful behavior to authors
fantasai: It does something which is "hey, try to figure out the
mapping before and after"
fantasai: in the most obvious way
fantasai: Two obvious ways are, does it match IDs, and is it the same
element?
fantasai: with ID being more explicit of a signal, so it wins
fantasai: I think the polls about "what auto does" mixes up with a
concept of auto-generated string
fantasai: If you think about identity about a string, auto could be
thought of as genning such a string
fantasai: but that's not what "auto" usually means in CSS.
fantasai: Here it's just "if there's some reasonable auto notion of
matching, use that"
fantasai: and this lets us use the same view transition for a bunch
of elements without having to name them individually
astearns: So would you object to removing auto for now?
fantasai: Yes
JakeA: match-element, I think people think it's more useful than it
actually is
JakeA: If you think of them as page transitions, that's what they're
for right now...
JakeA: They don't work in practice, because parts of the UI get...
JakeA: We had an overlay in the list we reordered, we had to put that
in the VT as well, but because it becomes inert that didn't
work for us
JakeA: we need scoped VTs for reordering
astearns: Noam had to leave and we're at timebox - I think I'll cut
you off and we'll move on
bramus: I'll defer to the issue as well
astearns: So take this back to the issue. It wasn't a quick
discussion, we'll bring it up again.
CSS Color Adjust
================
Should forced-colors support `color-mix()`?
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11097
ChrisL: Everyone implements color-mix() with system colors. we use
rgb value of those colors
ChrisL: All good
ChrisL: But what to do in forced colors mode?
ChrisL: Spec says computed value is the mixture, used value is
overridden by a system color
ChrisL: That's what chrome does. Firefox lets you mix it, so you can
do opacity variations/etc
ChrisL: Should this be allowed?
emilio: I implemented firefox behavior. I think it's reasonable, it
was a specific request from other engineers on firefox desktop
emilio: I have more concerns about relative colors, which have the
same kind of issue
emilio: but I think as long as the arguments are system colors or
transparent, it's reasonable to allow
emilio: but I don't care too strongly
kbabbitt: As I commented in the issue, the goal of forced colors is
to give the user control over the contrast settings that
they're seeing
kbabbitt: so I think mixing them and reflecting that value in the
computed result is fine, but what actually gets presented
to the user should be reflective of their chosen palette,
which precludes mixed colors
kbabbitt: For UI concerns, I have a brief example in the issue,
there's other ways to reflect the states that someone might
use mixed or partially transparent styles for. Using
different outline styles, for example. I've seen this in
high-contrast UIs to work around it being limited
emilio: That puts a lot of burden on authors, though.
emilio: A lot easier to say, like, "my buttons have system colors on
fg and bg, and hover states are variations of that"
emilio: A lot of generic CSS I've seen uses currentcolor and
transparent
emilio: Don't see the point of allowing currentcolor and not system
colors
emilio: If you don't allow it, you put the burden on authors to
change the whole stylesheet, rather than things just working
lea: What exactly is the proposed behavior if we don't allow it?
invalid at parse time? how are authors supposed to deal, use MQs?
lea: I was wondering, instead of disallowing certain things, can we
just allow anything and cast the result to the closet allowed
color at used value time?
lea: That seems better for DX, unsure if feasible
ChrisL: That's pretty much what the spec says, that you pick the
closest allowed color
ChrisL: Closest not being particularly well defined
lea: Then I'm missing something, why wouldn't we allow color-mix()?
ChrisL: We do allow color-mix(), the question is what to do with the
result
ChrisL: Use the computed value, or one of the forced values
lea: I'd expect it to produce the result, then see which allowed
color it's closest to
<ChrisL> agree
emilio: In firefox there's no particularly well-defined notion of
what's "closest"
emilio: firefox actually gives youthe mixed color and you can use it
lea: I'd be surprised if the spec doesn't have a well-defined notion
of closet
<ChrisL> "the UA determines the appropriate forced system
color—which should match the color that would result
from an empty author style sheet whenever all of the
element’s affected properties are likewise UA-determined."
<ChrisL> ie handwaving
<lea> oof. We should *at least* provide a way to determine closest,
even if non-normative
florian: Regardless of that, I think the spec and chrome do snap the
result to the closest color; the question is whether we do
chrome or firefox behavior
emilio: I think chrome probably treats it something closer to revert
florian: You mean chrome doesn't pick the closest color, it just
chooses something?
emilio: I'd be surprised, yes. I think it's more like if you use any
other non-allowed color
kbabbitt: I expect what emilio said is correct. Blink sees the
color-mix(), sees it's not a system color, and substitutes
TabAtkins: With regards to emilio's point about being able to do
generic stylesheets that slightly change colors, part of
the deal is, that subtle distinction would be invisible to
users of forced colors mode anyway
TabAtkins: those authors are using identical colors in such a state
anyway
TabAtkins: Those authors should be doing something different in
forced colors mode regardless
kbabbitt: +1 to what Tab just said
kbabbitt: also priority of constituencies, should lean to user
preference for what they're seeing than author convenience
emilio: I see two kinds of forced color users. Ones that need a
specific color palette, and ones that just want one.
emilio: Depending on which user, the color-mix() works great for the
latter
emilio: I agree you need to do something with more contrast for the
former case, but allowing color-mix() doesn't preclude that.
It does make life easier for the second class.
<lea> I'm still very confused. E.g. what is the result of `color:
color-mix(in lab, allowedColor1 0%, allowedColor2);`? It should
not be different than `color: color-mix(in lab, allowedColor1,
allowedColor2 100%);` or `color: allowedColor2`
astearns: I think user needs should override user wants
florian: The primary intent of this feature is a11y, not theming
florian: It *might* be used by people who like certain colors, but
the primary intent is for people who need those colors
florian: If it happens to work for the theme enjoyers, great, but
we're not designing toward them
emilio: But Tab's point is, for those users it might not make a
difference either way
TabAtkins: Not necessarily. If it's subtle, might not be
distinguishable
TabAtkins: if not subtle, could defeat the contrast goals of the user
<ChrisL> tab++
TabAtkins: if using their chosen colors, then good for them
kbabbitt: On need vs want, another feature is preferred color
schemes, a better fit for users who just *want* dark mode
or a particular set of colors but can tolerate mixes
kbabbitt: but as others have said, forced colors is primarily about
users who *need* that level of contrast
stepheckles: I've seen articles recently with folks becoming aware of
color-scheme property, and discovering system colors as
a part.
stepheckles: Trying to get the ability to produce light/dark agnostic
themes, before we have better support for light-dark()
stepheckles: Also, the example in the GH issue didn't even use the
forced-colors MQ
stepheckles: So want to clarify - does color-mix() using system
colors automatically get overriden because it's not a
system color?
stepheckles: I think if authors have a specific reason to need a
specific color to work, like color swatches for
products, they still have the ability to use
forced-color-adjust
ChrisL: Slightly confused about what was asking
ChrisL: System colors work the same way as normal colors
ChrisL: but specifically *when* we're in forced colors mode, there's
this overriding
stepheckles: The first examples in the issue just describe some
examples without forced-colors MQ in use, so it's a
little confusing
ChrisL: I linked to a codepen, when we're not in forced colors it
seems like all browsers are happy to use system colors, mix
them, etc
astearns: So I think I'm hearing we should resolve on no change to
the spec, and consider firefox's forced-colors behavior to
be a bug
astearns: emilio, do you want to go back to the people with this
request and have a convo?
emilio: I could. I think this isn't the right decision, but I don't
want to object.
emilio: If you have a disabled button, being able to make
semi-transparent button text...
emilio: We don't have a great set of system colors to reflect the
relevant state. this gives you the escape hatch to modify
system colors for that
emilio: I think in the ideal world we'd have system colors for all
the states authors care about
<TabAtkins> (making the text low contrast for disabled buttons is,
very specifically, the behavior we want to avoid for
forced-colors users, fwiw)
ChrisL: We've seen some good example of only changing opacity,
probably benign. But if we allow color-mix to be used in
general, people can do all kinds of wacky stuff, people can
defeat the point of the mode. So I'm comfortable with it
being overridden.
emilio: But authors could just use forced-color-adjust:none, right?
astearns: Counter is that's the authors specifically *choosing* to
override forced colors mode. Allowing color-mix() to work
allows them to screw up colors by accident.
emilio: I think overall they could do more good than harm, but I'm
not objecting.
astearns: Anyone else who'd object to resolving this no change?
RESOLVED: Close no change.
emilio: I guess by extension we should disallow relative colors?
ChrisL: Yes, I'll open a separate issue due to time
CSS Conditional
===============
scroll-state(overflowing) is confusing because it ignores clipped
overflowing content
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11182
futhark: There's scroll-state(overflowing) which is true if there is
content overflowing and scrollable to in that axis
futhark: Elika points out that there may be overflowing content that
can't be scrolled to. She recommends renaming the value to
'scrollable'
<miriam> +1 scrollable
<argyle> +1 scrollable
futhark: I agree. Suggest we use this name unless people have other
suggestions.
<TabAtkins> +1
fantasai: I think this is a good summary
<kbabbitt> +1 scrollable
astearns: Proposed resolution is to rename 'overflowing' to
'scrollable'
smfr: Is this only user-scrollable overflow? or also overflow:hidden,
which can be programmatically scrolled?
futhark: Overflowing content that can be scrolled to *with the UI*
kizu: yeah same, in a lot of aspects 'hidden' behaves as other
scrollable values like 'auto' or 'scroll'
kizu: I think there are situations authors might want to know if
there is clipped content that could be script-scrolled to
<emilio> I think it should apply to hidden fwiw
<emilio> (but not clip)
fantasai: Maybe a separate issue, I think I agree it should apply to
hidden as well
fantasai: The author knows if it's hidden or not, this becomes an
uninteresting query for hidden elements if it doesn't work
on hidden
fantasai: but I think that should be another issue
<TabAtkins> +1 to fantasai
astearns: Are you okay punting to a separate issue?
kizu: Yup
astearns: So proposed resolution, rename "overflowing" to
"scrollable". objections?
<emilio> +1 on the rename
RESOLVED: Rename "overflowing" to "scrollable"
<emilio> +1 to make it work on hidden too :)
astearns: I'll get the other two async resolutions going today.
<emilio> There's no point on allowing auto with scrollbar-width: none
but not hidden for example
F2F Scheduling
==============
fantasai: We had a poll for scheduling the f2f, would be great to
finish out respondents
<fantasai> https://app.rallly.co/invite/ShjWRuGtqnQG
fantasai: we have a lot of responses, so I'll close it soon and start
looking at scheduling space
fantasai: it's looking like probably Feb 6th
Received on Friday, 22 November 2024 23:03:18 UTC