- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Nov 2024 16:49:29 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-ui] UA stylesheet for appearance:base `<select>` ``.
<details><summary>The full IRC log of that discussion</summary>
<chrishtr> jarhar: have a list of additional properties proposed for the UA stylesheet. Think we should just go through them one-by-one.<br>
<chrishtr> first rule: padding: 025em<br>
<chrishtr> without this rule, the text in the button would stick to the borders, this centers it<br>
<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<br>
<chrishtr> emilio: the select has a border right?<br>
<chrishtr> jarhar: going to propose to remove the border actually<br>
<chrishtr> jarhar: that way you don't have two borders<br>
<chrishtr> jarhar: this was discussed on a separate issue with tim<br>
<jensimmons> q+<br>
<astearns> ack fantasai<br>
<emilio> q+<br>
<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.<br>
<chrishtr> jarhar: display: inline-block should answer that question (there is a proposed UA rule for it)<br>
<chrishtr> fantasai: and it directly contains text? and if there is a provided button it shows the button?<br>
<chrishtr> fantasai: there was a discussion about a pseudo elements, where did that go?<br>
<chrishtr> jarhar: we decided not to have a fallback UA pseudo element in this case, and instead the select element itself should be it<br>
<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?<br>
<chrishtr> jarhar: yes<br>
<chrishtr> jarhar: think we could do several adjustments if the button is there<br>
<annevk> (display: contents might make focus funky too)<br>
<chrishtr> fantasai: from an author's perspective should not see things change just because you added markup<br>
<masonf> What if we add `select>button {border:0; padding:0}` instead? And leave select's borders and padding.<br>
<emilio> `select > button { display: contents }`? :)<br>
<astearns> ack jensimmons<br>
<fantasai> or maybe select > button { display: contents; }<br>
<chrishtr> jensimmons: interesting that we have styling that depends on content<br>
<chrishtr> jensimmons: don't know of another case that works that way<br>
<chrishtr> jensimmons: not sure if authors would be confused by that or not<br>
<chrishtr> jensimmons: for the sake of these conversations more visuals would be n ice<br>
<astearns> q+<br>
<chrishtr> jensimmons: don't know what to think right now but want to help get it done, there might be bikeshedding.<br>
<masonf> Some common examples and use cases are detailed here: https://developer.chrome.com/blog/rfc-customizable-select<br>
<chrishtr> jensimmons: can't tell<br>
<astearns> ack emilio<br>
<chrishtr> emilio: maybe the button shouldn't have decorations and should delegate that to the select element. display:contents on the button<br>
<chrishtr> emilio: that may be a simpler option that avoids magic<br>
<chrishtr> emilio: also have feedback on the min sizing<br>
<keithamus> q+<br>
<chrishtr> emilio: 24px may be too big<br>
<chrishtr> emilio: white-space: normal seems find<br>
<chrishtr> emilio: 2px block and 1px inline padding already exists?<br>
<chrishtr> emilio: overall, the fewer rules the better<br>
<chrishtr> emilio: display:contents could explain has behavior<br>
<annevk> q+ to bring up the topic of how this relates to base styling of other controls<br>
<masonf> q+<br>
<chrishtr> emilio: maybe also make it !important<br>
<astearns> ack fantasai<br>
<chrishtr> fantasai: agree display: contents on the button make sense<br>
<chrishtr> fantasai: no need for !important<br>
<chrishtr> fantasai: considering pixel values for padding, I am in favor of em because it'll scale with font sizing<br>
<chrishtr> fantasai: font-relative is good<br>
<annevk> (.25em seems quite big, that's 4px)<br>
<chrishtr> fantasai: not sure why 0.25, where did that come from?<br>
<fantasai> s/0.25/1.2em/<br>
<dbaron> many of these things are based on the existing UA stylesheet rules for <select><br>
<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.<br>
<chrishtr> emilio: if existing padding is ok then let's try to accept it<br>
<jarhar> q?<br>
<jensimmons> q+<br>
<chrishtr> astearns: uncomfortable with having a switch on select content that is not expressed in the UA stylesheet<br>
<emilio> `select:has(> button) { ... }` should work<br>
<chrishtr> astearns: if we have things in the UA style sheet that depends on some state we should avoid that and fix it<br>
<astearns> ack astearns<br>
<ntim> I like Elika's suggestion of making button display: contents<br>
<annevk> (I agree with that to an extent, there's definitely things that are just not worth generalizing to CSS syntax.)<br>
<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.<br>
<chrishtr> keithamus: in favor of the rule as it stands. 24px minimum size is useful. should consider a11y, and WCAG recommends that<br>
<chrishtr> keithamus: I'd prefer even larger but smaller gets quite problematic<br>
<masonf> Rule #3 here says we need to follow WCAG: https://github.com/w3c/csswg-drafts/issues/10866<br>
<annevk> (E.g., detecting iso-8859-8-i.)<br>
<chrishtr> keithamus: 0.25em is also good, a lot of design systems use it<br>
<chrishtr> keithamus: need good defaults for modern-day practices and a11y practices. This is an opportunity to set good defaults.<br>
<astearns> +1 to not always following current styling<br>
<fantasai> strong +1 to keithamus<br>
<chrishtr> keithamus: should avoid making it too complicated, but since it's easy for authors to customize it doesn't get in their way<br>
<annevk> Can't it just be `select > button`?<br>
<chrishtr> keithamus: display: contents is problematic, might be confusing to developers. also might have a11y problems<br>
<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<br>
<astearns> q?<br>
<astearns> ack keithamus<br>
<astearns> ack annevk<br>
<Zakim> annevk, you wanted to bring up the topic of how this relates to base styling of other controls<br>
<chrishtr> annevk: one meta point is that as we decide on these rules it'll have implications for base styles for other controls<br>
<chrishtr> annevk: if we decide padding or sizing here then it should make sense for other controls<br>
<chrishtr> annevk: don't want to have to revisit for other form controls<br>
<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<br>
<chrishtr> annevk: if you just use a child selector then we could override its border and padding to be 0?<br>
<emilio> So `select > button { appearance: none; padding: 0; border: 0 }`?<br>
<chrishtr> annevk: if you're styling this button will its appearance be?<br>
<astearns> ack masonf<br>
<chrishtr> mason: one rule we're following is to follow WCAG, which is where 24px came from<br>
<chrishtr> s/mason/masonry/<br>
<chrishtr> s/mason/masonf/<br>
<chrishtr> masonf: agree that we could have a rule like what Emilio wrote to remove appearance and put 0 padding and border<br>
<jensimmons> q-<br>
<chrishtr> jarhar: the way we implemented it is that if the button is present then focus delegates to it, including focus rings<br>
<chrishtr> jarhar: if there is no button then the select element itself gets the focus<br>
<emilio> display: contents on the button seems like a nicer fix for the focus issue tbh :)<br>
<emilio> q+<br>
<chrishtr> masonf: others said let's inherit padding when possible from appearance: auto. I think we should fix them to be good.<br>
<astearns> ack fantasai<br>
<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<br>
<annevk> I think if the `button` is being styled in the UA style sheet we need to figure out `appearance: base` for it.<br>
<astearns> +1 to not making !important rules in the UA stylesheet if we can avoid it<br>
<annevk> (I use webirc.w3.org and it keeps dropping me from the channel. I wish we'd use something that's not IRC.)<br>
<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<br>
<keithamus> q+<br>
<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.<br>
<chrishtr> fantasai: the button should be a markup extra that somehow doesn't need that complication<br>
<astearns> ack emilio<br>
<chrishtr> fantasai: if the purpose of the button is to clarify hierarchies then limit to that, and make it display: contents !important<br>
<chrishtr> emilio: happy to concede on the padding<br>
<fantasai> +1 emilio<br>
<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<br>
<astearns> ack keithamus<br>
<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<br>
<chrishtr> keithamus: they will also have CSS around focus, active, etc<br>
<masonf> q+<br>
<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<br>
<astearns> ack masonf<br>
<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<br>
<jarhar> q?<br>
<chrishtr> masonf: display: contents seems weird from that perspective<br>
<jarhar> q+<br>
<ntim> q+<br>
<astearns> ack jarhar<br>
<annevk> What's the use case for the custom button? How does display: contents not invalidate that use case?<br>
<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?<br>
<chrishtr> jarhar: we can't reuse the slot element, but maybe a new element or concept?<br>
<jensimmons> No, we should use <button> not a <div> + new slot thing.<br>
<chrishtr> annevk: the slot API is a web developer API.<br>
<jensimmons> q+<br>
<chrishtr> annevk: don't care about the button element that much, it's the content?<br>
<chrishtr> annevk: maybe an appearance:base button could help?<br>
<astearns> ack ntim<br>
<chrishtr> ntim: before thinking about the styles with the button case, want to step back - what use cases will people use buttons for?<br>
<chrishtr> ntim: if it's used for a split button then display: contents is probably not right<br>
<keithamus> q+<br>
<chrishtr> ntim: would be nice to see a list of use cases<br>
<masonf> Some examples with custom buttons here: https://developer.chrome.com/blog/rfc-customizable-select<br>
<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<br>
<chrishtr> jarhar: a big use case is declaratively copying the selected option into the button<br>
<chrishtr> jarhar: without providing them with a button, it precludes them putting their own or rich content into the in-page select element part<br>
<chrishtr> jarhar: without doing this we'll miss most use cases<br>
<masonf> q+<br>
<chrishtr> ntim: does it allow for split buttons?<br>
<chrishtr> jarhar: there has been a lot of discussion at OpenUI with experts<br>
<annevk> q+ why do we need both button and selectedoption?<br>
<annevk> q+ to ask why do we need both button and selectedoption?<br>
<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<br>
<astearns> ack jensimmons<br>
<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.<br>
<chrishtr> jensimmons: we're trying to fix some decisions made back in the 90s<br>
<annevk> q-<br>
<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<br>
<chrishtr> jensimmons: without confusing authors<br>
<astearns> ack keithamus<br>
<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.<br>
<chrishtr> keithamus: need to make sure it has accessible defaults, and that the styles aren't too difficult to override<br>
<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`<br>
<astearns> ack masonf<br>
<fantasai> In that case, wouldn't you just style select { display: flex; } ?<br>
<chrishtr> masonf: roughly +1 to what jen and keith said. agree authors will reset it. Minimal is better.<br>
<chrishtr> masonf: we've been staring at this screen for an hour, but it's a quarter of the entire proposed style sheet<br>
<chrishtr> masonf: suggest we iterate in the issue instead of live<br>
<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<br>
<chrishtr> astearns: want to amplify Joey's point that the justification is in the comment, please reply on the issue<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10857#issuecomment-2462743355 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 November 2024 16:49:30 UTC