- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 22 Nov 2024 19:34:55 -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
================================
Selectors
---------
- The group agreed to remove :closed for now and keep :open (Issue
#11039: Should we have :open and :closed?)
CSS UI
------
- RESOLVED: Use currentColor for borders, inherit the color,
transparent background color (for in-page controls). Use
system colors for pickers (Issue #10909: Colors to use
for appearance:base `<select>`)
- jahrar presented slides (
https://lists.w3.org/Archives/Public/www-archive/2024Nov/0002.html )
for issue #10857 (UA stylesheet for appearance:base `<select>`)
and requested feedback and questions in github.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/whatwg/html/issues/10778
Present:
Joey Arhar
David Baron
Brecht De Ruyte
Elika Etemad
Mason Freed
Chris Harrelson
David Leininger
Tim Nguyen
Cassondra Roberts
Alan Stearns
Anne van Kesteren
Greg Whitworth
Scribe: gregwhitworth
Scribe's scribe: masonf
Selectors
=========
Should we have :open and :closed?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/11039
jarhar: I tried to spec the open and closed pseudo classes in HTML
that are in CSS and I was informed that they are redundant
and remove the :closed pseudo selector
brecht_dr: One benefit of having :closed is you can select a sibling
in CSS with that state and you can make that default and
only do it on open
brecht_dr: I see some benefit to having this as well and we have this
with disabled and almost no one uses enabled
anne: In those cases you can use :not(:open)
anne: If there are controls we might provide a picker; :close would
not always match unless there is an open state
anne: At least until we have a better handle on that open is easier
and in the scenario where you'll know there is a picker you can
do :not(:open)
dbaron: I think historically CSS has pairs is so that you can
distinguish between the ones they apply and those they don't
dbaron: :close only matches things that could be :open
dbaron: Could definition could be non-trivial to be defined and as we
talk about inputs that "could" have a picker is not a trivial
thing and :close would only apply to a picker like "color",
"date" would match if they have a picker and they are closed
now
gregwhitworth: I feel like, David, you agreed with Anne, you can do
that with not
dbaron: With input its harder to do that with not because you need to
write input type= and get the selector for type exactly right
and then put not open
dbaron: It's harder to do with :not on inputs is you need to get the
type attribute correct
anne: I don't think we want to expose which controls have a picker
anne: :closed would expose which controls have a picker
ntim: The reason that is an issue is that the picker is not set and
it may vary
ntim: the set of elements that have a picker is not finalized*
anne: iOS select multiple has a picker vs inline compared with Desktop
jarhar: I really would like to move this forward and I'm fine with
removing closed for now, does someone have strong feelings to
keep closed right out of the gate
<masonf> proposed resolution: support :open for now, leave :closed
for later.
argyle: Yeah, it seems obvious to include them and we think
:not(:open) is the same then it seems solvable and they
should be provided
anne: :closed would only match an element that HAS a picker and that
capability may change over time
anne: :open will only match if the picker is shown and that will
require a user action
argyle: We can determine that today correct?
anne: Whether it's web observable or not
argyle: Isn't that a pseudo element of picker() making it web
observable?
argyle: As someone coming into this we have :open but not :close?
ntim: The main problem here is someone uses :close selector on the
web page and we expand the set of things that have pickers then
:close will apply to more things with no action
ntim: It's a compat hazard and it doesn't require any action for it
to apply
argyle: Can we teach "closed" to be to :not(:open)
ntim: There is a difference
masonf: This is akin to appearance: base in that there is compat
concerns and once we have all the controls that have pickers
we may come back and address them?
anne: Maybe, we have to figure out the platform "thing"
anne: There was TAG feedback on whether these should be feasible
or not
anne: So I think that would be TBD
<jarhar> proposed resolution: remove :closed for now and keep :open
argyle: I'm in agreement with jarhar that sympathizes and I'll not
blocking it
<masonf> +1
CSS UI
======
Colors to use for appearance:base `<select>`
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10909
ntim: [Presenting a presentation on proposed colors]
Slides: https://lists.w3.org/Archives/Public/www-archive/2024Nov/0003.html
masonf: Thank you for the preso and history lesson
masonf: My question is about forced colors and I assumed we would
need the MQ but it seems like you found we may not need to do
that?
ntim: It's always ensured with currentcolor and transparent background
ntim: You don't get the semantic colors that the user has defined
<dbaron> The resolution
https://github.com/w3c/csswg-drafts/issues/11097#issuecomment-2489223857
from yesterday might be relevant here
dbaron: Yesterday the CSSWG had a discussion around forced-color and
color-mix and it doesn't allow you to override the colors as
it falls back to the set
ntim: That may mean that we don't need the special color
dbaron: The flip side is the risk that in forced colors mode there is
no way to identify disabled style
brecht_dr: The one example you showed us with the one covered in
yellow
brecht_dr: I'm curious if this works but is this something that can
be annoying that you're using this in forced colors?
brecht_dr: I don't know but I would like to know as this would be
annoying
ntim: The idea is not only for HC but also for cognitive disability
for instance everything that is blue is a button
ntim: Everything that is green is a text input, etc
ntim: The user preference is the thing to respect here regardless
ntim: We want to force system colors in forced-colors mode and the
theory of how is to just do what works
masonf: The first one is the proposal about transparency and
currentcolor and system colors
argyle: I'm curious if this proposal that we would like ghost styling
for all form inputs as though it's a div with a border and
would have no background
fantasai: Correct
masonf: By default, of course the dev could add one
argyle: We have colors in system colors
fantasai: But none that are guaranteed to have contrast with system
colors
masonf: What is the problem
argyle: I see more issues with this than currentcolor with system
colors than this
fantasai: It's the background that is underneath unless you change
the color on the input
fantasai: You can get into this today
fantasai: You can set the color without setting the background color
today and true since CSS1
argyle: I would have assumed everything is accessible by default
argyle: it comes with healthy defaults for background + text, etc
<ntim> PROPOSED RESOLUTION: Use currentColor for borders, inherit the
color, transparent background color (for in-page controls).
Use system colors for pickers.
<ntim> We force system colors in forced colors mode, figure out what
would be the best mechanism.
fantasai: You'll get this if you set the color to the background that
doesn't contrast with the background
argyle: I don't know a design system that is ghost alone
ntim: Material Design
ntim: the proposal inherits the color from the parent element
argyle: They have an inherited contrast and they could have good
contrast out of the box
anne: none of the HTML elements have their own background
anne: that's the reasoning behind this proposal
anne: isn't that the point of this
argyle: I thought the principle was to make this "safe" and
accessible by default
fantasai: What is the difference between this and an H3
argyle: I'm not saying they're the same
<fantasai> or a <strong> element
anne: They have the same requirements
anne: How are they different
argyle: They have states and interactivity
argyle: They're quite different
anne: none of those impact the styles
ntim: People expect backgrounds behind them is that we expect them
and there is no extra background requirement
argyle: If you want to go super minimal and that's the most minimal
starting place and you're saying people will fix it
fantasai: If it's not they have bigger problems
brecht_dr: I do think it's important to have base because you decided
to set it to that but I do understand from argyle and
differentiation from that and a div
brecht_dr: if you have a border on an H3 and an interactive element
right from the start
brecht_dr: I'm not sure if that is right
fantasai: We don't have a border on H3 on it
fantasai: Maybe you want to make some style changes then
brecht_dr: I agree on that
<masonf> On a white background, that's the case today though.
<fantasai> +1 masonf
brecht_dr: You want something is contrasted and not contrasted
gregwhitworth: When we kicked off appearance:base, the styles will be
interoperable. That was fundamental.
gregwhitworth: When you do appearance:base, you know how everything
will be. We did a lot of research on forced contrast.
In theory, even today you can collide colors.
gregwhitworth: Interoperable styles - we have the same DOM and same
styles. I'd prefer background colors, because that's
how I build them, but I can easily do that. Just add a
background-color. I'll always do that.
gregwhitworth: Tim, there's a difference between popovers and
inlines, right? On popovers there will be a background
color.
ntim: Right.
chrishtr: The most important thing is compatible styles that are easy
to override and the second most is consistency with how
elements work with the web
chrishtr: Second thing we can stroll poll
<masonf> Straw poll: 1) transparent background colors, 2) system
colors
<dbaron> Is the straw poll just about the in-page part of the
controls?
<fantasai> Should be, yes
davidleininger: I want to be clear on appearance: base is that
currentcolor comes into inputs as that doesn't
currently work
davidleininger: There are so many other little things that can impact
this
fantasai: We inherit from the parent, not from the body
davidleininger: If it inherits from the parent and it inherits from
the parent and it's a mismatch how do we handle that?
ntim: The text color inherits from the parent and the background of
parent inherits as well so as long as the contrast is correct
then this should work
davidleininger: I can see this not having a reasonable pair and
you're putting a background on a fieldset but it's
not meant to be transparent, I can see it causing
potential issues and maybe that's something we're
ok with
ntim: You'll want to set the text color on the fieldset if you're
setting the background
davidleininger: I'm not going to lose sleep over it
<masonf> Straw poll: for *in-page controls* (not popover pickers): 1)
transparent background colors, 2) system colors
<argyle> "base" could learn a lot from the wildly popular "headless
ui" libs, since that sounds like what this group is hoping
"base" can be?
<argyle> https://nerdy.dev/headless-boneless-and-skinless-ui#headless-ui
<fantasai> masonf, you forgot about inheriting the color :)
<fantasai> maybe? POLL: for *in-page* part of the control (not
popover pickers): 1) inherit 'color', transparent
'background' or 2) use system colors
<masonf> fantasai, yeah. Colors *are* inherited, they're just
overridden in the current stylesheet. Right?
<masonf> +1 to fantasai's version of the poll. Just to be completely
transparent. ;-)
anne: So they would not set the color property
davidleininger: People build things in terrible ways all the time
davidleininger: I'm going to throw this standard element inside of
this element and it's going to house the form but the
form is white and they use a div that is grey
background and they apply appearance: base and it's a
grey one now there is no background
davidleininger: The have had a white background for so long that it
could mess with things
anne: They could not use the H3 in that context
anne: If you set display: none on your root should we disable that?
davidleininger: We're not making that the default
masonf: The label on the element on the would not have contrast
dandclark: I'll agree with gregwhitworth and chrishtr is the priority
and either of these options are viable for that
dandclark: Apologies if I missed this and we need to have multiple
colors such as range, seems like we're locked into one
foreground color?
dandclark: How would you expect that to work
ntim: We could use mixes of current color with lumances and have one
color, etc
<dbaron> POLL: for *in-page* part of the control (not popover
pickers): 1) inherit 'color', transparent 'background' or 2)
use system colors
<argyle> #2
<masonf> 1+
<masonf> 1
<chrishtr> 1
<ntim> 1
<fantasai> 1
<gregwhitworth> abstain
<astearns> abstain
<jarhar> 1
<dbaron> 1
<davidleininger> 2
<dandclark> 1
<emilio> 2
<brecht_dr> 2
RESOLVED: Use currentColor for borders, inherit the color,
transparent background color (for in-page controls). Use
system colors for pickers.
<ntim> We force system colors in forced colors mode, figure out what
would be the best mechanism.
UA stylesheet for appearance:base `<select>`
--------------------------------------------
scribe: dbaron
github: https://github.com/w3c/csswg-drafts/issues/10857
jarhar: [presents presentation]
Slides: https://lists.w3.org/Archives/Public/www-archive/2024Nov/0002.html
<argyle> margin-inline-start instead of justify-content, how come?
justify-content will continue to work if authors put
checkmarks on the inline-end, where inline-start only works
for checkmarks at the start
<emilio> Can we avoid flex / border-radius? The less we change the
general layout model the better, IMHO...
fantasai: Key question here is do we make buttons look different from
inputs. If yes, second question applies, and we need to
decide how. Proposal is using either background-color,
border-radius, or both.
fantasai: Advantage of background-color is it's something authors
will almost always override anyway. But if we use a
background color it's more likely to run into color
contrast than if we use a border-radius.
fantasai: We should try to make minimal differences. I'd probably go
with a or b and not c so there's fewer things to override.
brecht_dr: I agree with ??
brecht_dr: Resetting things gets tedious, fewer things to reset is
better.
Received on Saturday, 23 November 2024 00:35:31 UTC