- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 28 Oct 2024 18:37:52 -0400
- To: www-style@w3.org
- Cc: 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.
=========================================
CSS UI
------
- RESOLVED: Add pseudo-elements for the select button and option
checkmarks which are fully stylable pseudo-elements with
content specified by the content property (Issue #10908:
Pseudo-elements for checkmark and dropdown icon for
appearance:base <select>)
- RESOLVED: Adopt ::check or ::checkmark for checkbox/radio checks
- jarhar will open an issue to determine if pseudo elements (yet to
be named) are tree-like or element-like
- The group reviewed the potential implementation of the proposal for
issue #10909
https://github.com/w3c/csswg-drafts/issues/10909#issuecomment-2435550602
.
There was concerns that border being currentColor was both
non-intuitive for developers and going to cause additional work
to change. There was discussion around the pros and cons of using
system colors which would make something predictable, but also
may cause issues for things like high contrast mode. Discussion
will return to github.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/whatwg/html/issues/10702
Present:
Joey Arhar
David Baron
Tantek Çelik
Keith Cirkel
Emilio Cobos Álvarez
Elika Etemad
Mason Freed
David Leininger
Tim Nguyen
Cassondra Roberts
Anne van Kesteren
Greg Whitworth
Chair: gregwhitworth
Scribe: gregwhitworth
Customizable select stage 3 request
===================================
github: https://github.com/whatwg/html/issues/9799#issue-1914386972
jarhar: In WHATWG there is an open issue for select option issue
which we'll be discussing today in Open UI; I still have a
lot of WHATWG specs that are open PRs that are linked in the
agenda
CSS UI
======
Pseudo-elements for checkmark and dropdown icon for
appearance:base <select>
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10908
jarhar: We decided a while ago to use new pseudo elements rather than
before and after in the UA stylesheets but we need to
determine the behavior and what their names will be
<masonf> ::check and ::select-arrow
jarhar: The best option right now is tree abiding pseudo elements and
they'll behave like :before and :after and call them ::check
and ::select-arrow
<fantasai> +1 to fully styleable pseudo-elements like ::before etc.
emilio: Is the plan to make content work on them?
JakeA: Yes, content should work like :before and :after
emilio: What is the ordering of this
fantasai: They should come in the middle since they're functionally
content
<jarhar> ::check is before ::before, and ::select-arrow is after
::after
emilio: The check is like a marker which goes before the ::before
emilio: I could see it both ways
keithamus: My question was going to bikeshed on the arrow word as
it's prescriptive of the shape when it may not be an
arrow; but it's whatever
<masonf> ::select-activator
<masonf> ::select-opener
fantasai: We could go with ::open or something like that
fantasai: ::field-button-open
fantasai: That makes it reusable for other buttons
anne: Is it a button icon?
<dbaron> ::open-button ?
jarhar: I like button-icon better than ::open state
<davidleininger> ::select-toggle
<masonf> +1 to ::open-button
emilio: Button is odd too because you can put icons within the button
emilio: It's not worse though, so I'm ok with that
emilio: I thought part of this was the option checkmark
emilio: I don't have a strong opinion as long as we decide something
dbaron: There are a few more options on IRC
dbaron: ::select-opener, ::open-button, ::select-activator,
::select-toggle
<keithamus> ::select-indicator
emilio: it feels weird because the whole button opens the select
<davidleininger> +1 ::select-indicator
<masonf> +1 ::select-indicator or ::select-icon
gregwhitworth: I like keithamus ::select-indicator
<anne> I don't think it's an indicator, the whole button indicates
the state.
gregwhitworth: To Elika's point, is there a way to generalize it at
all? so that we don't end up with 30 indicators?
masonf: It's more specific than ::before and ::after
fantasai: Do we want this to be the thing that opens other popups
<fantasai> ::field-popup-icon
emilio: Is there any prior art?
<fantasai> ::field-open-icon
<fantasai> ::field-open-button
masonf: The more that I think about it we should be thinking of the
pickers
masonf: in all cases it's an icon but it shouldn't have the word
select in it
anne: I guess that's fine, the weird thing is that the activation
region is different for them
anne: maybe that's fine
fantasai: When you have an autocomplete field it only activates on
top of the icon, and in that case the activation region
it's the same but we'll want to use the same name
<keithamus> Ant: suffixIcon
<keithamus> Orange: select-indicator
<keithamus> Carbon: select-arrow
<keithamus> Evergreen: caret-down
<keithamus> Primer: trailing-visual
<keithamus> Material: dropdown-icon
emilio: For what it's worth the gecko thing that does the
show-password thing and others and I called it ::button-box
but that's kind of what it is
keithamus: Going through design systems and I don't see anything
super inspiring
argyle: There are two in there for webkit is indicator and button
masonf: That makes me think it should have picker in there somewhere
since that is common
argyle: The indicator forces the autocomplete
anne: The definition of indicator shows the state and this does not
keithamus: it can as it may open and rotate to show state
anne: and it's the only thing that we call indicator it will show the
whole state of the widget which it doesn't
<masonf> ::picker-icon ?
<jarhar> I like ::picker-icon because for select its not a button but
for date inputs it is a button
<fantasai> ::picker-icon or ::picker-button seems reasonable
<gregwhitworth> +1 to ::picker-icon
<masonf> +1 to ::picker-icon
<keithamus> Soft +1 to ::picker-icon. I don't love the connotations
of "icon" but it seems the least-worst.
emilio: You're not going to use it for non-picker things right?
emilio: Will you use it for clear icon?
fantasai: Those would get different names
<argyle> `::picker-invoker`?
<argyle> here's a search input to see this things stacking
https://cdpn.io/pen/debug/WNLZqYZ
<argyle> https://usercontent.irccloud-cdn.com/file/iL5PuLBR/Screenshot%202024-10-24%20at%208.21.55%E2%80%AFAM.png
fantasai: If we're re-using this for different forms we're indexing
really hard on select and there are many controls where the
active region is the thing you're interacting with
fantasai: In almost every other case it is the button that you click
fantasai: Maybe we call it picker-button since that's the more common
scenario but <select> is a bit odd
masonf: I'm ok with that too. From a user's POV it really does feel
like it's a button.
keithamus: Does that mean for date picker you would have to open the
date picker via button?
anne: I don't think that's true
fantasai: I think it means there are more things that can open the
platform.
masonf: In some cases other things can open the picker but in all
cases the button will open the picker
anne: I'm ok with button, you can have a label or similar
keithamus: I don't want to bikeshed everything and they'll assume
this is a button
fantasai: It's a pseudo element though but it needs to activate in
some way
fantasai: All of them should have a consistent word but it seems like
the obvious one
keithamus: Anyone against ::picker-opener
fantasai: We have file-selector-button
<masonf> So choices are ::picker-icon, ::picker-button,
::picker-opener
<argyle> `::picker-toggle` `::picker-invoker`?
davidleininger: In chat it was a trigger or an action
davidleininger: if it's going to close it it shouldn't be activator
<masonf> So choices are 1) ::picker-icon, 2) ::picker-button,
3) ::picker-opener, 4) ::picker-toggle, 5)::picker-invoker,
6) ::picker-trigger
<masonf> maybe we vote?
<gregwhitworth> +1 masonf
ntim: When we prefix it with something the pseudo element is inside
that thing, that means it's inside the picker
<ntim> disclosure ?
<fantasai> INFORMAL POLL
<keithamus> 3
<jarhar> 1
<fantasai> 2
<masonf> 1
<anne> 2
<dbaron> 3
<davidleininger> 6
<gregwhitworth> 1
<argyle> 2
<tantek> +1 take it back to the issue - with reasoning for each
<tantek> abstains from the choice of name, has insufficient context
to offer an informed opinion
<dbaron> (I lean towards 3 because some of them seem too confusable
with *parts* of the ::picker().)
<ntim> I like none of these, but if I had to pick it would be 1)
jarhar: There was discussion prior to names that were about it being
a tree abiding pseudo and where it resides
<masonf> +1
<fantasai> PROPOSED: This is a fully styleable tree-abiding
pseudo-element
anne: Does that mean that we would make all pseudo elements tree
abiding?
fantasai: I thought there was resolution on that
<jarhar> proposed resolution: add pseudo-elements for the select
button and option checkmarks which are tree-abiding
pseudo-elements with content specified by the content
property
<masonf> +1
<keithamus> +1
<fantasai> +1
<jarhar> proposed resolution: add pseudo-elements for the select
button and option checkmarks which are tree-abiding
pseudo-elements which accepts all properties with content
specified by the content property
<fantasai> https://drafts.csswg.org/css-pseudo-4/#treelike
<jarhar> proposed resolution: add pseudo-elements for the select
button and option checkmarks which are fully stylable
tree-abiding pseudo-elements with content specified by the
content property
anne: Does this mean that picker open no longer matches because I
would be ok with that
anne: I'm not talking about the select element but the picker pseudo
element
fantasai: That is not the same pseudo element as it has stuff inside
fantasai: These don't exist without having a content set to something
other than a string
<emilio> I guess the main question is if these are part-like (in
which case we need to put them between before and after)
<emilio> or more before/after like
anne: A concern at TPAC raised by Jen was consistency which is what
I'm after here
<tantek> +1 concern about consistency across pseudo-elements
fantasai: For these, I think ::before and ::after
dbaron: These are currently defined "part" like pseudo elements and
it is more element like and the content property doesn't work
there
anne: Some pseudo classes won't work with tree abiding
fantasai: We want to be consistent with ::before and ::after here
fantasai: There was a lot of confusion of what "part" like means here
and I've removed it from the draft
fantasai: They are simple empty pseudo elements and should be like
::marker, etc
fantasai: We'll need to think about ::picker() more
anne: For customizable select it seems imminent
anne: It seems like a stage 3 blocker
fantasai: Maybe
fantasai: It will need to be able to point back to a pseudo class
masonf: Can we resolve on the other issue
anne: I was trying to make them consistent
dbaron: The distinction that are leaves vs the ones that are
containers and we should be consistent with their behaviors
masonf: I've been thinking of those as tree abiding and part like
dbaron: The spec says tree abiding and element backed
masonf: ::picker is a container and what we're discussing here are
the leaves
masonf: Maybe that's the question you're asking anne?
anne: Should they have different behaviors and that they should have
different API surface
masonf: Definitely don't support content
anne: You can only apply content with images?
anne: You can replace a <p> with an image
<anne> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ap%20%7B%20content%3Aurl(image)%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3ETESt
dbaron: The spec says you can but maybe not completely "not"
implemented
fantasai: The state of the content draft is sketchy
dbaron: The other question is whether you can do strings
anne: I agree that it's broken but it's unclear what the right
model is
fantasai: But that's largely a compat issue around that area
fantasai: That constrained what ::before and ::after could be
<fantasai> and what styles real elements could accept
<fantasai> https://drafts.csswg.org/css-pseudo-4/#treelike
<fantasai> https://drafts.csswg.org/css-pseudo-4/#element-like
<fantasai> should make those hyphens consistent, hm
<masonf> proposed resolution: add pseudo-elements for the select
button and option checkmarks which are fully stylable
pseudo-elements with content specified by the content
property
RESOLVED: Add pseudo-elements for the select button and option
checkmarks which are fully stylable pseudo-elements with
content specified by the content property
<emilio> so, 100% not part-like?
<emilio> That's fine I suppose but those are more restricted than part
ACTION: jarhar to open an issue to determine if pseudo elements (yet
to be named) are tree-like or element-like
<RRSAgent> records action 1
masonf: are there objections to check?
fantasai: the only other option is checkmark
fantasai: which may make it easier
<ntim> I like check
<ntim> shorter
masonf: I kind of like checkmark
RESOLVED: Adopt ::check or ::checkmark for checkbox/radio checks
Colors to use for appearance:base `<select>`
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10909
<jarhar> https://github.com/w3c/csswg-drafts/issues/10909#issuecomment-2435550602
jarhar: In this comment which I posted, I tried to take Tim's
proposed colors for appearance: base and use them in select
jarhar: The one thing that may not have been fully implemented is the
background color for the popover/picker
jarhar: Do people like these, do you not like these? ntim does this
meet what you were thinking?
<fantasai> background: Field; needs to be paired with background:
FieldText; to ensure contrast
keithamus: I'm not super stoked about the border being currentColor
jarhar: Why do you not like that?
keithamus: I don't think it's that prevalent and I think a lot of
design systems will adjust them and if the currentColor or
textColor which will impact the border color it will
create more work for devs
keithamus: I know it's probably controversial but there's opportunity
to add a color keyword which will be preferable, akin to
accent-color. That's what design systems do
keithamus: we assign a custom property define a color but they rarely
if ever attach to current color
<masonf> Wouldn't that be weird though because borders don't inherit?
<fantasai> Note the initial value of `border-color` is `currentColor`
ntim: We discussed this proposal internally and having a special
keyword for border keyword is a default that ensures contrast.
The only one that ensures contrast is currentColor
ntim: I don't think this is really feasible
jensimmons: If I understand what you were saying, is that it seems
weird to authors have borders absorb currentColor and why
would that change border colors
jensimmons: I was on your side but we're really boxed in here, what
if we invented a new system color and not any of the above
jensimmons: and we went down every rabbit hole, I hate it but I'm
convinced
jensimmons: I posted on mastadon and 70% of devs got it wrong
<fantasai> color = foreground color
<fantasai> therefore also the default border-color
jensimmons: People think that color == text color when the whole
color of the thing means the whole color except for the
parts that you have changed
jensimmons: If you set color to green then you use the pseudo to
change text-color, etc
jensimmons: I can't reproduce the convos we've had
<jensimmons> This was my survey on Mastodon:
https://front-end.social/@jensimmons/113312399553267089
keithamus: I don't want to downplay them but some things jump out
at me
keithamus: You say 70% of devs got it wrong and we're going to follow
the opposite of their intuition
keithamus: We have the opportunity to get it right today and set us
on a path to help them
keithamus: ntim said two things, but contrast function that allows us
to ensure it so we could use that? And what contrast are
we trying to adhere to here?
keithamus: ntim you mentioned the background is transparent
jensimmons: That was an argument I kept making, if they change the
color of the background and they haven't yet changed the
borders, they're going to change them
jensimmons: There are other states like high-contrast mode that we
can map to them then that something else needs to tie
into it
jensimmons: I didn't know high contrast mode existed on Windows and
you can't test that on Mac
jensimmons: there may be different ways to set this
jensimmons: Regarding the background being transparent; this is just
an experiment and we should debate them and maybe they're
not the right color. Everything else doesn't have a
background unless you add it
<emilio> Button / ButtonText / ButtonBorder do exist already fwiw,
and they do work as you expect.
emilio: I was going to make the opposite point is that if you make
the background transparent then you actually don't get the
system colors and that seems a bit odd and the default should
behave better than that
emilio: We do have system colors that do map almost to what we want,
and we could define them to have something consistent and add
some states but we can make them work
emilio: We can spec them to do the correct thing and high contrast
works and you don't get the weird behavior where text colors
impact border colors
emilio: it's also how native buttons are styles already
<tantek> FYI: changing color sets the border-color by default is from
CSS1 https://www.w3.org/TR/REC-CSS1/#border-color
emilio: I just want to raise that if we go with transparent option we
need to acknowledge that things like high contrast are not
going to work like we expect
emilio: Let's get some base colors and system keywords that do
something sensible and don't do anything fancy and that gets
the right behavior
dbaron: There was a point that fantasai made in IRC about system
colors and the more I think about the popup being a system
color brings the whole philosophy into question
dbaron: We want to only take the styles from the page and not have
system colors, and the popup has to have a background as it
will just overlap stuff and this proposal give a system color
background and you have to match them in pairs and you need
to ensure contrast in pairs
<emilio> +1
dbaron: What fantasai said as well is that we need to give the popup
a system color as well but is calling the whole philosophy as
well. Maybe it's ok that the in page parts don't have these
but the picker uses system colors for background
ntim: To dbaron's point, dialog and popover use system colors by
default in the UA stylesheet
ntim: It wouldn't be going away from what we have now and have the in
page follow one paradigm and it wouldn't go against prior art.
I agree with fantasai that we should use pairs in popup to have
system background colors
<emilio> Right, but then the question is why not doing the same
everywhere else (not just popups)?
Received on Monday, 28 October 2024 22:38:26 UTC