Re: [csswg-drafts] [css-forms-1] Should auto or none appearance inherit (#12931)

The CSS Working Group just discussed `[css-forms-1] Should auto or none appearance inherit`.

<details><summary>The full IRC log of that discussion</summary>
&lt;cwilso> q?<br>
&lt;noamr> lwarlow: I guess with appearance:base you do want it to apply<br>
&lt;dbaron> The beginning of this discussion was incorrectly minuted to https://github.com/whatwg/html/issues/11819#issuecomment-3468618193 instead<br>
&lt;noamr> lwarlow: if you inherit appearance:none you get an appearance:none button<br>
&lt;noamr> zcorpan: so the issue is that it's hard to work with appearance:base<br>
&lt;noamr> lwarlow: we can make it inherit which doesn't work for auto<br>
&lt;cwilso> ack next<br>
&lt;noamr> lwarlow: we can make more complex rules but it gets messier<br>
&lt;noamr> jarhar: in chromium we have appearance in the computed style, but also "effective appearance", these rules about not inheriting is in "effective appearnce". it's very nuanced, e.g. for file-input<br>
&lt;noamr> jarhar: fixing this would correct the script-exposed value. but for implementations it's easier to do this in "effective appearance"<br>
&lt;noamr> jarhar: I think we should correct all of this in "effective appearance"<br>
&lt;noamr> annevk: can you clarify?<br>
&lt;noamr> jarhar: leave as is, implement the requirements in the effective appearance and not in computed style<br>
&lt;noamr> lwarlow: only for appearance base, also in other cases?<br>
&lt;noamr> jarhar: I will be surprised if people are mixing and matching these now, e.g. for slider<br>
&lt;noamr> zcorpan: for file picker, if we want to make it easier to use appearance:base, we can specify that it affects the button<br>
&lt;noamr> zcorpan: this can make it easier for web devs without introducing problems<br>
&lt;noamr> annevk: this should be the developer story<br>
&lt;noamr> annevk: ideally none and auto are consistent<br>
&lt;noamr> zcorpan: auto and none are equivalent for file picker<br>
&lt;noamr> annevk: not sure if it's worth changing the default<br>
&lt;noamr> lwarlow: can update the spec so that it's not done by computed style, mention the special cases<br>
&lt;noamr> lwarlow: that solves that side of things<br>
&lt;noamr> annevk: not sure for what extents we should specify effective appearance, but it would be nice if at least for base the pseudo-elements returned the right value, or a reasonable story<br>
&lt;noamr> lwarlow: I think that should be doable by chrome's implementation<br>
&lt;jarhar> q?<br>
&lt;masonf> q+<br>
&lt;cwilso> ack next<br>
&lt;noamr> masonf: are we saying we're not going to allow a pseudo element to override the originating element?<br>
&lt;noamr> lwarlow: at least for appearance: base that's good<br>
&lt;noamr> masonf: why should the developer not get the option to mix/match?<br>
&lt;noamr> lwarlow: appearance:auto gives the control to the OS<br>
&lt;noamr> annevk: the picker is a separate window; sometimes you want to force that kind of rendering<br>
&lt;noamr> annevk: that's why the picker is a separate case<br>
&lt;noamr> lwarlow: the picker itself isn't really the select. it's coincidental that the picker is part of the select. For file picker, the fact that it's a button is not exposed anywhere<br>
&lt;noamr> masonf: was just curious, not a strong convinction. what about e.g. number input? e.g. have the up/down buttons be auto but not the rest<br>
&lt;noamr> annevk: we're not currently particularly interested in this<br>
&lt;noamr> zcorpan: can introduce a lot of complexity<br>
&lt;noamr> annevk: for new appearance auto inputs we won't allow pseudos<br>
&lt;noamr> lwarlow: can we resolve on computed vs. used value time? e.g. we can special case file-input at used value time<br>
&lt;noamr> lwarlow: and we can get rid of the special rule if we can switch it to auto<br>
&lt;noamr> annevk: I'm convinced that we can go with the easier implementation, not exposed the used value<br>
&lt;noamr> emilio: we can look at the root control appearance value except for in file input. we do that effectively in range input<br>
&lt;noamr> emilio: it's the same as "used value" in a way<br>
&lt;noamr> annevk: you just look at the control's appearance value and not the pseudo's<br>
&lt;noamr> zcorpan: it's probably web compatible to change the appearance to auto for file-input<br>
&lt;noamr> emilio: the q is whether you want file-input appearance:none to change the buttons<br>
&lt;noamr> zcorpan: that might break pages<br>
&lt;noamr> emilio: carving out the file input is probably fine. it's like an independent part. Unlike range tracks<br>
&lt;masonf> In Chrome, setting appearance:auto on the input and appearance:none on the button does change the button rendering today<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12931#issuecomment-3468724950 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 30 October 2025 15:53:29 UTC