- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Dec 2024 16:40:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-ui] UA stylesheet for appearance:base `<select>` ``, and agreed to the following: * `RESOLVED: have the same border radius for base appearance for selects and buttons, conditional on giving others not present a week to review.` * `RESOLVED: use transparent background color for base appearance selects, buttons, and inputs` <details><summary>The full IRC log of that discussion</summary> <keithamus> jarhar: we discussed colors last time. Some discussion in the thread; fantasai made a nice list. I made a recent comment to use the same background color for both and distinguish with border radius only<br> <keithamus> jarhar: I;d like to get a resolution if possible<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/10857#issuecomment-2515767151<br> <keithamus> annevk: Tim and Jen aren't here - can we do a tentative resolution to hear feedback from them?<br> <keithamus> astearns: we'll often take a full resolution with the caveat in it, waiting to act until people are able to take a look<br> <keithamus> annevk: thats workable<br> <keithamus> astearns: so one at a time, jarhar suggested we _only_ use border radius, not background or color to distinguish. Can you go into reasoning?<br> <keithamus> jarhar: alternative to using same background to both is inputs having transparent, and buttons having color mix.<br> <keithamus> jarhar: in some offline discussions I recall Tim making it fully transparent, also Tab likes fully transparent more. It sounds fine.<br> <keithamus> jarhar: People seem to have a preference for fully transparent.<br> <keithamus> astearns: So background and background color out because of the transparency possibility? Border radius was the original option presented, is there anything beside radius?<br> <keithamus> jarhar: good question<br> <keithamus> astearns: not opposed, just want to make sure we're deciding right<br> <fantasai> Could use box-shadow<br> <lwarlow> q+<br> <keithamus> jarhar: with the objective in mind of trying to use background-color for select - why I'm interested in this resolution - I'm not saying we can't make further distinctions but I'd like to settle on border-radius/background color<br> <astearns> ack lwarlow<br> <keithamus> lwarlow: my preference would be buttons/inputs/selects all have the same base style. I'm not sure adding border-radius facilitates anything?<br> <keithamus> lwarlow: background color doesn't change anything... border radius is going to be changed. I don't think it makes sense to have a default.<br> <keithamus> lwarlow: open question of should we distinguish them; probably no from me. A uniform look for interactive elements.<br> <keithamus> q+<br> <keithamus> lwarlow: inputs have popups with their own inputs, an input isn't that different to a select.<br> <jarhar> keithamus: im not disagreeing with luke but i think border radius is fine. other thing is text align right? i imagine that text align center is on buttons and selects and text align left is on inputs. is that something that we're going to do?<br> <fantasai> +1 to text-align<br> <keithamus> masonf: text align start in select, button is unset.<br> <fantasai> +1 to astearns's point<br> <keithamus> astearns: we can certainly consider it as part of the stylesheet but not a distinguishing mark<br> <lwarlow> Personally I see text-align start more for selects and inputs but not for button<br> <keithamus> astearns: I think in most cases inputs are start aligned, but text aligned is inherited from other content - so a UI centered aligned will have centered aligned inputs<br> <jarhar> q?<br> <masonf> q+<br> <keithamus> ack keithamus<br> <jarhar> q+<br> <keithamus> annevk: if you have an input element with an initial value and you have a button can you distinguish by just looking at them?<br> <keithamus> annevk: if they just have a border?<br> <astearns> ack masonf<br> <keithamus> masonf: to clarify, we seem to have agreed we're not using the 10% background and going fully transparent?<br> <keithamus> astearns: that's my understanding<br> <keithamus> masonf: the thing I wanted to say, being able to distinguish inputs vs buttons vs selects - the one that seems special is the button. Clicking on others isn't destructive, a button _does_ something, you click on it and oops it was a submit button<br> <keithamus> masonf: making input/select is fine, and we should focus more on button for this discussion<br> <astearns> ack jarhar<br> <keithamus> jarhar: my goal was to align selects with buttons as opposed to inputs<br> <keithamus> jarhar: in the interests of distinguishing between the two, border radius is a good way to do that, since it's on the table right now. As for text-align I haven't explored in a ton of detail. Some content to think about.<br> <lwarlow> q+<br> <keithamus> jarhar: Right now just interested in the border color, background color, border radius<br> <keithamus> jarhar: so are people okay with border radius?<br> <astearns> ack lwarlow<br> <keithamus> astearns: I suspect people are fine with not changing background colro<br> <keithamus> astearns: I suspect people are fine with not changing background color<br> <keithamus> lwarlow: 0.25 and 0 are effectively the same - I can't tell the difference with my eyesight. If we want to distinguish them we should also use a colour<br> <keithamus> fantasai: thats a quarter of a font-size. Should be significant<br> <keithamus> lwarlow: my eyesight might be bad<br> <keithamus> annevk: 4 css pixels? Not a whole lot.<br> <keithamus> q+<br> <astearns> ack keithamus<br> <keithamus> keithamus: font-weight: bold might be useful in addition too<br> <fantasai> We could do 0.5em<br> <fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%201px%3B%20padding%3A%200.25em%3B%20border-radius%3A%200.5em%22%3Etest%3C%2Fdiv%3E<br> <keithamus> masonf: buttons with more border radius to make it look different - half an em for the button to show its really rounded could show it's different.<br> <keithamus> annevk: I would assume we'd use the same style for button and select<br> <keithamus> annevk: I'm concerned about the distinction between text controls and buttons<br> <keithamus> annevk: can you click it vs edit it is a thing you might want to tell by looking at it<br> <keithamus> masonf: but for the user nothing scary about - if you click it and nothing bad happens<br> <keithamus> q+<br> <keithamus> masonf: you can abort without penalties<br> <keithamus> masonf: but button is scary<br> <fantasai> +1 masonf<br> <keithamus> annevk: but last time we came to the conclusion that select style impact how we style button<br> <fantasai> s/you can/for select, you can/<br> <lwarlow> q+<br> <keithamus> annevk: if we only use border radius to distinguish, is that sufficient or not?<br> <keithamus> annevk: the select concerns get grouped with button<br> <keithamus> annevk: select could look like a text input... I thought jarhar was also doing that<br> <keithamus> masonf: cursor style tells you a bit about it too<br> <astearns> ack keithamus<br> <jarhar> keithamus: select and buttons have visually distinct style because of dropdown marker. but also to masons point of buttons doing the dangerous thing, i think it is ambiguous. if we are deciding based on that factor, buttons don't always do the dangerous thing. a lot of buttons in websites are to build select equiavelent things. to annes point,<br> <jarhar> there is validity in making combobox and select visually distinct. one of those is ediable and one is read only. there should be a distinction. theres a caret but thats not sufficient<br> <jarhar> keithamus: both points are correct to a degree, but theres probably additional distinguishing things to add.<br> <jarhar> keithamus: text inputs we can have them as border with no border radius with no background, normal font weight<br> <jarhar> keithamus: select could be styled like a button. but we know that selects arent going to be dangerous because they have visual treatment<br> <jarhar> keithamus: combobox needs to look like a mish mash of the two. have the triangle but look like an input?<br> <jarhar> keithamus: buttons need to have a style but authors can decide how dangerous theyre going to be and they can style them<br> <jarhar> keithamus: thats how i see it. i think we should have a very distinguishable style for buttons and selects should look like buttons. editable form controls should have a distinguishable style<br> <astearns> ack lwarlow<br> <keithamus> lwarlow: keithamus touched on some of what I am thinking; buttons aren't always dangerous. customisable select is very literally a button that opens a popover. I think that we're using a button element in a select says they should be treated relatively similar<br> <keithamus> lwarlow: border radius alone is _probably_ enough, we just need to figure out a value<br> <keithamus> lwarlow: something masonf touched on around the cursor is a good point too<br> <keithamus> qq+<br> <astearns> ack keithamus<br> <Zakim> keithamus, you wanted to react to lwarlow<br> <keithamus> ack keithamus<br> <keithamus> fantasai: I think 0.5em would be a better size for border radius<br> <keithamus> fantasai: masonf's point was compelling on where to use it. That's all I have<br> <masonf> So the variables we have available to distinguish input, select, button are: border-radius, text-align, cursor, and the presence of ::picker-icon.<br> <keithamus> astearns: sounds like we're converging on select and buttons using the same border-radius<br> <emilio> +1 on making buttons and select the same<br> <keithamus> masonf: should background-color be included in that?<br> <jarhar> proposed resolution: have the same border radius for base appearance for selects and buttons, conditional on giving others not present a week to review.<br> <keithamus> +1<br> <dandclark> +1<br> <masonf> +1<br> <fantasai> wfm<br> <keithamus> emilio: +1 on making select/button similar, but I am still uneasy about adding border-radius only on appearance base. The more computed value time dependencies we add the more we complicate reasoning about css.<br> <keithamus> astearns: can you describe cvt issue you're seeing?<br> <keithamus> emilio: appearance effecting border-radius<br> <keithamus> emilio: either with magic css that UAs can only use or with magic adjustments after we've.... it feels very odd<br> <keithamus> emilio: it makes dependency tracking between properties more annoying<br> <keithamus> emilio: I'd like to change as little as possible for appearance base styles<br> <jarhar> q+<br> <astearns> ack fantasai<br> <keithamus> annevk: yeah I feel like we're revisiting old ground. appearance base opts into new ground where you can apply with an internal at-rule or a value function to open the ability to make a good default style sheet for these controls<br> <keithamus> annevk: if we need to litigate each property for the improved style sheet that's gonna take up a lot of time<br> <keithamus> emilio: its something we can do when we think its needed but border-radius is presentational.<br> <keithamus> astearns: so while we're not re litigating the entire idea of a style sheet we should be conservative about it<br> <keithamus> masonf: we should think of it as a new control but not be chained to the past.<br> <fantasai> +1 to masonf<br> <masonf> q?<br> <keithamus> annevk: the discomfort for me is not so much... the argument from emilio seems to be implementation difficulty, not that border-radius is bad for these controls. I have a problem with that argument, not how conservative we are<br> <keithamus> annevk: I have a problem with saying no against a property because it's hard to implement<br> <emilio> not implementation difficulty<br> <astearns> ack jarhar<br> <emilio> More like hardness of reasoning about it as an author<br> <masonf> q+<br> <keithamus> jarhar: making properties change based on appearance has been implemented in chrome for some time now, at first it was more complicated due to the css parser changes needed, but Andrej from the style team did a refactor that made all the magic parsing go away and we have a new internal base appearance thing for pretty much any property<br> <keithamus> jarhar: I did need to set the appearance base to be a high priority property but it's worked so far and I'm using it a lot and it's working great. I have no worries with changing any of these properties we're discussing<br> <astearns> ack masonf<br> <keithamus> masonf: I think authors won't think about the magic required, they'll just look at the new styles<br> <keithamus> q+<br> <astearns> ack fantasai<br> <keithamus> fantasai: from an author perspective you're switching between two different style modes. There's no intra-property dependencies, it's just a different base style sheet.<br> <jarhar> keithamus: we have two concreate user bases here. one is theyre never going to customize anything and they need sensible defaults. anyone who is going to customize these styles, theyre going to customize as much as they need to. if they need to change the border radius they will<br> <jarhar> fantasai: its also an obvious one to change<br> <astearns> proposed resolution: have the same border radius for base appearance for selects and buttons, conditional on giving others not present a week to review.<br> <keithamus> +1<br> <masonf> still +1<br> <jarhar> +1<br> <jarhar> RESOLVED: have the same border radius for base appearance for selects and buttons, conditional on giving others not present a week to review.<br> <jarhar> proposed resolution: use transparent background color for base appearance selects, buttons, and inputs<br> <keithamus> +1<br> <masonf> +1<br> <fantasai> +1<br> <lwarlow> +1<br> <jarhar> RESOLVED: use transparent background color for base appearance selects, buttons, and inputs<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-2520875011 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 5 December 2024 16:40:41 UTC