15:58:37 <RRSAgent> RRSAgent has joined #css
15:58:41 <RRSAgent> logging to https://www.w3.org/2024/11/07-css-irc
15:58:41 <Zakim> RRSAgent, make logs Public
15:58:43 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:59:11 <astearns> topic Nov 7 form controls agenda: https://github.com/whatwg/html/issues/10730
16:02:02 <castastrophe> castastrophe has joined #css
16:03:32 <masonf> masonf has joined #css
16:03:56 <castastrophe> present+
16:04:02 <emilio> present+
16:04:20 <chrishtr> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10909
16:04:21 <github-bot> Topic: [css-ui] Colors to use for appearance:base `<select>`
16:04:21 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10909.
16:04:24 <chrishtr> present+
16:05:27 <jensimmons> jensimmons has joined #css
16:05:38 <jarhar> jarhar has joined #css
16:05:42 <dbaron> github: none
16:05:43 <chrishtr> github- bot, take up https://github.com/w3c/csswg-drafts/issues/10857
16:06:10 <dbaron> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10857
16:06:10 <github-bot> Topic: [css-ui] UA stylesheet for appearance:base `<select>`
16:06:10 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10857.
16:07:04 <chrishtr> jarhar: have a list of additional properties proposed for the UA stylesheet. Think we should just go through them one-by-one.
16:07:23 <masonf> present+
16:08:08 <chrishtr> first rule: padding: 025em
16:08:20 <chrishtr> without this rule, the text in the button would stick to the borders, this centers it
16:09:07 <chrishtr> 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 deccoration
16:09:42 <chrishtr> emilio: the select has a border right?
16:09:52 <chrishtr> jarhar: going to propose to remove the border actually
16:10:05 <chrishtr> jarhar: that way you don't have two borders
16:10:12 <chrishtr> jarhar: this was discussed on a separate issue with tim
16:10:36 <jensimmons> q+
16:10:45 <astearns> ack fantasai
16:10:47 <annevk> annevk has joined #css
16:10:50 <emilio> q+
16:10:56 <zcorpan> zcorpan has joined #css
16:11:12 <chrishtr> 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.
16:11:33 <chrishtr> jarhar: display: inline-block should answer that question (there is a proposed UA rule for it)
16:11:53 <chrishtr> fantasai: and it directly contains text? and if there is a provided button it shows the button?
16:12:06 <chrishtr> fantasai: there was a discussion about a pseudo elements, where did that go?
16:12:29 <chrishtr> jarhar: we decided not to have a fallback UA pseudo element in this case, and instead the select element itself should be it
16:12:58 <chrishtr> 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?
16:13:04 <chrishtr> jarhar: yes
16:13:21 <chrishtr> jarhar: think we could do several adjustments if the button is there
16:13:40 <annevk> (display: contents might make focus funky too)
16:14:12 <chrishtr> fantasai: from an author's perspective should not see things change just because you added markup
16:14:13 <masonf> What if we add `select>button {border:0; padding:0}` instead? And leave select's borders and padding.
16:14:19 <emilio> `select > button { display: contents }`? :)
16:14:21 <astearns> ack jensimmons
16:14:26 <fantasai> or maybe select > button  { display: contents; }
16:14:42 <chrishtr> jensimmons: interesting that we have styling that depends on content
16:14:51 <chrishtr> jensimmons: don't know of another case that works that way
16:15:07 <chrishtr> jensimmons: not sure if authors would be confused by that or not
16:15:20 <chrishtr> jensimmons: for the sake of these conversations more visuals would be n ice
16:15:55 <ntim> ntim has joined #css
16:16:06 <astearns> q+
16:16:22 <chrishtr> jensimmons: don't know what to think right now but want to help get it done, there might be bikeshedding.
16:16:28 <masonf> Some common examples and use cases are detailed here: https://developer.chrome.com/blog/rfc-customizable-select
16:16:31 <chrishtr> jensimmons: can't tell
16:16:33 <astearns> ack emilio
16:17:03 <chrishtr> emilio: maybe the button shouldn't have decorations and should delegate that to the select element. display:contents on the button
16:17:12 <chrishtr> emilio: that may be a simpler option that avoids magic
16:17:26 <chrishtr> emilio: also have feedback on the min sizing
16:17:41 <keithamus> q+
16:17:51 <chrishtr> emilio: 24px may be too big
16:17:59 <chrishtr> emilio: white-space: normal seems find
16:18:15 <chrishtr> emilio: 2px block and 1px inline padding already exists?
16:18:29 <chrishtr> emilio: overall, the fewer rules the better
16:18:46 <chrishtr> emilio: display:contents could explain has behavior
16:19:14 <annevk> q+ to bring up the topic of how this relates to base styling of other controls
16:19:20 <masonf> q+
16:19:20 <chrishtr> emilio: maybe also make it !important
16:19:34 <astearns> ack fantasai
16:19:48 <chrishtr> fantasai: agree display: contents on the button make sense
16:19:55 <chrishtr> fantasai: no need for !important
16:20:14 <chrishtr> fantasai: considering pixel values for padding, I am in favor of em because it'll scale with font sizing
16:20:32 <chrishtr> fantasai: font-relative is good
16:20:35 <annevk> (.25em seems quite big, that's 4px)
16:20:40 <chrishtr> fantasai: not sure why 0.25, where did that come from?
16:20:48 <fantasai> s/0.25/1.2em/
16:21:06 <dbaron> many of these things are based on the existing UA stylesheet rules for <select>
16:21:20 <chrishtr> 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.
16:21:31 <chrishtr> emilio: if existing padding is ok then let's try to accept it
16:21:37 <jarhar> q?
16:21:38 <jensimmons> q+
16:21:57 <chrishtr> astearns: uncomfortable with having a switch on select content that is not expressed in the UA stylesheet
16:22:19 <emilio> `select:has(> button) { ... }` should work
16:22:24 <chrishtr> astearns: if we have things in the UA style sheet that depends on some state we should avoid that and fix it
16:22:25 <astearns> ack astearns
16:22:39 <ntim> I like Elika's suggestion of making button display: contents
16:22:42 <annevk> (I agree with that to an extent, there's definitely things that are just not worth generalizing to CSS syntax.)
16:22:51 <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.
16:22:52 <chrishtr> keithamus: in favor of the rule as it stands. 24px minimum size is useful. should consider a11y, and WCAG recommends that
16:23:04 <chrishtr> keithamus: I'd prefer even larger but smaller gets quite problematic
16:23:04 <masonf> Rule #3 here says we need to follow WCAG: https://github.com/w3c/csswg-drafts/issues/10866
16:23:12 <annevk> (E.g., detecting iso-8859-8-i.)
16:23:15 <chrishtr> keithamus: 0.25em is also good, a lot of design systems use it
16:23:48 <chrishtr> keithamus: need good defaults for modern-day practices and a11y practices. This is an opportunity to set good defaults.
16:23:51 <astearns> +1 to not always following current styling
16:23:55 <fantasai> strong +1 to keithamus
16:24:12 <chrishtr> keithamus: should avoid making it too complicated, but since it's easy for authors to customize it doesn't get in their way
16:24:41 <annevk> Can't it just be `select > button`?
16:24:41 <chrishtr> keithamus: display: contents is problematic, might be confusing to developers. also might have a11y problems
16:25:08 <chrishtr> 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
16:25:12 <astearns> q?
16:25:16 <astearns> ack keithamus
16:25:35 <astearns> ack annevk
16:25:35 <Zakim> annevk, you wanted to bring up the topic of how this relates to base styling of other controls
16:25:36 <chrishtr> annevk: one meta point is that as we decide on these rules it'll have implications for base styles for other controls
16:25:50 <chrishtr> annevk: if we decide padding or sizing here then it should make sense for other controls
16:26:10 <chrishtr> annevk: don't want to have to revisit for other form controls
16:26:30 <chrishtr> annevk: with regards to display: contents, there are a lot of implications of display: contents for focus and so on that make it tricky
16:26:42 <chrishtr> annevk: if you just use a child selector then we could override its border and padding to be 0?
16:27:03 <emilio> So `select > button { appearance: none; padding: 0; border: 0 }`?
16:27:05 <chrishtr> annevk: if you're styling this button will its appearance be?
16:27:07 <astearns> ack masonf
16:27:33 <chrishtr> mason: one rule we're following is to follow WCAG, which is where 24px came from
16:27:40 <chrishtr> s/mason/masonry/
16:27:46 <chrishtr> s/mason/masonf/
16:28:13 <chrishtr> masonf: agree that we could have a rule like what Emilio wrote to remove appearance and put 0 padding  and border
16:28:24 <jensimmons> q-
16:28:40 <chrishtr> jarhar: the way we implemented it is that if the button is present then focus delegates to it, including focus rings
16:28:51 <chrishtr> jarhar: if there is no button then the select element itself gets the focus
16:28:59 <emilio> display: contents on the button seems like a nicer fix for the focus issue tbh :)
16:29:00 <emilio> q+
16:29:43 <chrishtr> masonf: others said let's inherit padding when possible from appearance: auto. I think we should fix them to be good.
16:29:45 <astearns> ack fantasai
16:29:45 <Zakim> fantasai, you wanted to disagree with emilio, our priority should be to be a good, accessible, interoperable base for styling, not consistent with existing styles
16:29:50 <annevk> annevk has joined #css
16:29:53 <annevk> I think if the `button` is being styled in the UA style sheet we need to figure out `appearance: base` for it.
16:30:05 <astearns> +1 to not making !important rules in the UA stylesheet if we can avoid it
16:30:19 <annevk> (I use webirc.w3.org and it keeps dropping me from the channel. I wish we'd use something that's not IRC.)
16:30:24 <chrishtr> 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
16:30:44 <keithamus> q+
16:30:53 <chrishtr> 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.
16:31:13 <chrishtr> fantasai: the button should be a markup extra that somehow doesn't need that complication
16:31:48 <astearns> ack emilio
16:31:58 <chrishtr> fantasai: if the purpose of the button is to clarify hierarchies then limit to that, and make it display: contents !important
16:32:04 <chrishtr> emilio: happy to concede on the padding
16:32:33 <fantasai> +1 emilio
16:32:41 <chrishtr> 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
16:32:53 <astearns> ack keithamus
16:33:08 <chrishtr> 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
16:33:17 <chrishtr> keithamus: they will also have CSS around focus, active, etc
16:33:37 <masonf> q+
16:33:46 <chrishtr> 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
16:33:55 <astearns> ack masonf
16:34:24 <chrishtr> 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
16:34:37 <jarhar> q?
16:34:41 <chrishtr> masonf: display: contents seems weird from that perspective
16:34:41 <jarhar> q+
16:34:47 <ntim> q+
16:34:56 <astearns> ack jarhar
16:35:25 <annevk> What's the use case for the custom button? How does display: contents not invalidate that use case?
16:35:46 <chrishtr> 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?
16:36:18 <chrishtr> jarhar: we can't reuse the slot element, but maybe a new element or concept?
16:36:24 <jensimmons> No, we should use <button> not a <div> + new slot thing.
16:36:50 <chrishtr> annevk: the slot API is a web developer API.
16:36:51 <jensimmons> q+
16:37:49 <chrishtr> annevk: don't care about the button element that much, it's the content?
16:38:04 <chrishtr> annevk: maybe an appearance:base button could help?
16:38:34 <astearns> ack ntim
16:38:52 <chrishtr> ntim: before thinking about the styles with the button case, want to step back - what use cases will people use buttons for?
16:39:14 <chrishtr> ntim: if it's used for a split button then display: contents is probably not right
16:39:22 <keithamus> q+
16:39:26 <chrishtr> ntim: would be nice to see a list of use cases
16:39:27 <masonf> Some examples with custom buttons here: https://developer.chrome.com/blog/rfc-customizable-select
16:39:46 <chrishtr> 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
16:40:09 <chrishtr> jarhar: a big use case is declaratively copying the selected option into the button
16:40:32 <chrishtr> jarhar: without providing them with a button, it precludes them putting their own or rich content into the in-page select element part
16:40:48 <chrishtr> jarhar: without doing this we'll miss most use cases
16:40:49 <masonf> q+
16:41:11 <chrishtr> ntim: does it allow for split buttons?
16:41:27 <chrishtr> jarhar: there has been a lot of discussion at OpenUI with experts
16:41:27 <annevk> q+ why do we need both button and selectedoption?
16:41:32 <annevk> q+ to ask why do we need both button and selectedoption?
16:41:57 <chrishtr> 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
16:41:59 <astearns> ack jensimmons
16:42:50 <chrishtr> 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.
16:43:04 <chrishtr> jensimmons: we're trying to fix some decisions made back in the 90s
16:43:30 <annevk> q-
16:44:05 <chrishtr> 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
16:44:21 <chrishtr> jensimmons: without confusing authors
16:44:49 <robatadp5> robatadp5 has joined #CSS
16:44:52 <astearns> ack keithamus
16:45:30 <chrishtr> 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.
16:45:55 <chrishtr> keithamus: need to make sure it has accessible defaults, and that the styles aren't too difficult to override
16:46:10 <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`
16:46:37 <astearns> ack masonf
16:46:48 <fantasai> In that case, wouldn't you just style select { display: flex; } ?
16:47:06 <chrishtr> masonf: roughly +1 to what jen and keith said. agree authors will reset it. Minimal is better.
16:47:29 <chrishtr> masonf: we've been staring at this screen for an hour, but it's a quarter of the entire proposed style sheet
16:47:43 <chrishtr> masonf: suggest we iterate in the issue instead of live
16:49:07 <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
16:49:23 <chrishtr> astearns: want to amplify Joey's point that the justification is in the comment, please reply on the issue
16:49:28 <chrishtr> github-bot, take up https://github.com/w3c/csswg-drafts/issues/10909
16:49:28 <github-bot> Topic: [css-ui] Colors to use for appearance:base `<select>`
16:49:28 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10909.
16:49:59 <chrishtr> jarhar: last time we talked about this issue I tried to loop in Tim's proposed styles for buttons for appearance:base into selecct
16:50:08 <chrishtr> jarhar: also talked about system colors and contrast, and the picker
16:50:28 <chrishtr> jarhar: since then I've posted some styles that used Tim's proposed colors for in-page and system colors for picker
16:50:34 <chrishtr> jarhar: thought these would be reasonable defaults
16:50:50 <chrishtr> jarhar: Emilio proposed an alternative about system colors
16:51:05 <chrishtr> jarhar: I don't have strong opinions but would like to choose something
16:51:13 <ntim> q+
16:51:19 <astearns> ack ntim
16:51:20 <chrishtr> jarhar: Emilio liked system colors because it ensures contrast with all the modes
16:51:43 <chrishtr> ntim: my original suggestion of using currentcolor and transparency was to make in-page controls as easy to style as a blank div
16:52:13 <chrishtr> ntim: for the picker, we can't use transparency. think we should use system colors there. Dialogs and popovers use them by default also.
16:52:24 <chrishtr> ntim: everything I've proposed is consistent with other things in HTML
16:52:36 <emilio> q+
16:52:45 <astearns> ack emilio
16:53:07 <chrishtr> emilio: The main reason why I think system colors could be worth it is that it works with color scheme and forced colors.
16:53:33 <chrishtr> emilio: Also don't think it would be not too hard to do it. But don't object to using currentcolor etc
16:53:37 <masonf> q+
16:53:43 <astearns> ack masonf
16:54:13 <chrishtr> masonf: I think we should aim for having a thing that is easiest to understand, since developers are likely to override anyway.
16:54:32 <jensimmons> q+
16:54:42 <astearns> ack fantasai
16:54:44 <chrishtr> masonf: weakly in favor of what Emilio is proposing for that reason
16:54:55 <chrishtr> fantasai: the currentcolor approach is more minimal I think
16:55:14 <masonf> In devtools, they'll see that background-color is `color-mix(in lab, currentColor 10%, transparent)`
16:55:21 <jensimmons> 100% developers do not know that system colors exist. They will assume these are defined colors in the UA stylesheet.
16:55:32 <chrishtr> fantasai: they get colors either way, but fewer with currentcolor, so I think it's easier for them to override just that one
16:55:41 <astearns> ack jensimmons
16:56:03 <chrishtr> jensimmons: there are different groups of colors: text, borders, bits and pieces
16:56:18 <chrishtr> jensimmons: why are the backgrounds of my form a certain color?
16:56:35 <chrishtr> jensimmons: as soon as they change the color of the page it'll show a difference for their form
16:57:03 <chrishtr> jensimmons: nothing else on the page comes with a background color, so I think it's better for this to not have one eother
16:57:07 <keithamus> q+
16:57:08 <astearns> q+
16:57:23 <chrishtr> jensimmons: like the idea of a transparent background
16:57:30 <emilio> q+
16:57:32 <chrishtr> jensimmons: it's busywork to have to change that
16:57:42 <chrishtr> jensimmons: this makes them feel a pain in the ass to style
16:58:24 <astearns> ack keithamus
16:58:36 <chrishtr> keithamus: dialogs and popovers have canvas as the background color
16:58:46 <chrishtr> keithamus: my preference would be system colors
16:59:02 <astearns> ack astearns
16:59:03 <chrishtr> astearns: I wonder if using transparency would get us into problems with contrast
16:59:05 <astearns> ack emilio
16:59:11 <annevk> I think dialog and popover are different in that they are displayed in the top layer.
16:59:16 <annevk> Form controls are not.
16:59:21 <chrishtr> emilio: it doesn't necessarily cause contrast issues unless you use background images
16:59:41 <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.
16:59:49 <chrishtr> emilio: I think native app design systems do have background colors on their form controls?
17:00:12 <ntim> material design :)
17:00:12 <astearns> ack fantasai
17:00:18 <chrishtr> fantasai: is there a precedent for toolkits with transparent backgrounds?
17:00:23 <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?
17:00:36 <chrishtr> fantasai: if we go with system colors we'd have to define more of them
17:01:07 <chrishtr> fantasai: different systems also display select elements differently
17:02:07 <chrishtr> keithamus: system colors are an abstraction away from color mixing, but we're presumably sticking to one style
17:02:25 <chrishtr> emilio: nothing prevents us from mixing to currentcolor
17:02:42 <chrishtr> fantasai: system colors require contrast, but currrentcolor doesn't know what it is mixing with?
17:03:12 <chrishtr> fantasai: needs contrast be\tween system colors
17:03:23 <fantasai> (can't compute a system color to transparent)
17:03:58 <fantasai> +1 to understanding the developer experience better
17:04:24 <astearns> topic: end
17:04:31 <astearns> zakim, end meeting
17:04:31 <Zakim> As of this point the attendees have been castastrophe, emilio, chrishtr, masonf
17:04:33 <Zakim> RRSAgent, please draft minutes v2
17:04:35 <RRSAgent> I have made the request to generate https://www.w3.org/2024/11/07-css-minutes.html Zakim
17:04:42 <Zakim> I am happy to have been of service, astearns; please remember to excuse RRSAgent.  Goodbye
17:04:42 <Zakim> Zakim has left #css
17:07:11 <emilio> fantasai: for a concrete example, in Firefox for macOS HighlightText computes to currentColor and a semi-transparent selection background (https://searchfox.org/mozilla-central/rev/113b09cdd5282b39db65b2f62abe843558b9471a/widget/cocoa/nsLookAndFeel.mm#142-144,185-187)
17:09:00 <emilio> That is... any argument for lacking contrast with transparent system color applies too to styling appearance base with currentColor, doesn't it?
17:13:42 <jamesn> jamesn has joined #css
17:47:34 <fantasai> emilio: Maybe I didn't understand your suggestion?
18:00:02 <Adam_Page> Adam_Page has joined #css
18:11:12 <emilio> fantasai: my comment was that we could really make system colors work the same way as currentcolor-based stuff, while maybe making it work better for high contrast mode at the same time, if we really wanted
19:13:28 <bkardell_> bkardell_ has joined #css
19:38:09 <atrigent_> atrigent_ has joined #css
19:39:12 <atrigent__> atrigent__ has joined #css
20:19:41 <fantasai> emilio: Ah, ok. I think I understand what you're saying...
20:20:13 <fantasai> emilio: so we'd say that for `appearance: base`, the system colors would compute differently -- to variations of currentColor and transparent, instead of to their opaque colors.
20:20:26 <fantasai> emilio: and in high-contrast mode they would magically be the right colors
20:21:15 <fantasai> emilio: That seems cool, but I wonder if, once authors start tweaking the colors, we might end up with some mix of author-specified and system-specified colors because the author didn't realize that's what was happening under the hood.
20:23:49 <emilio> fantasai: right, but in forced colors you generally don't honor non-system-color author colors anyways
20:23:59 <emilio> So not sure it matters in practice
20:56:09 <atrigent_> atrigent_ has joined #css
21:40:18 <TabAtkins> fantasai, florian, where are the metadata requirements for various statuses documented? Trying to figure out if CRD actually requires a deadline or not.
21:40:34 <TabAtkins> (I have it listed as requiring one in <https://github.com/speced/bikeshed-boilerplate/blob/main/boilerplate/doctypes.kdl#L192>)
21:41:20 <TabAtkins> In particular, https://www.w3.org/standards/types/#x3-2-1-candidate-registry-draft doesn't list those things
22:02:23 <fantasai> TabAtkins: https://www.w3.org/pubrules/doc
22:28:07 <TabAtkins> danke