Re: [csswg-drafts] [css-forms-1] Define pseudo-classes for meter states (#11336)

The CSS Working Group just discussed `[css-forms-1] Define pseudo-classes for meter states`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> ntim: &lt;meter> has slider track and fill<br>
&lt;fantasai> ntim: In most implementations, depending on the attributes on the &lt;meter> element you get different colors.<br>
&lt;fantasai> ntim: If the meter has less than optimal value, it's red<br>
&lt;fantasai> ntim: could get red, green, or orange fill depending on the colors<br>
&lt;fantasai> ntim: Rules defined in HTML spec<br>
&lt;fantasai> ntim: Right now in webkit and blink, can style using pseudo-elements. But what we want is peudo-classes<br>
&lt;fantasai> ntim: And also need to define the rules for when they apply<br>
&lt;emilio> q+<br>
&lt;fantasai> TabAtkins: Suggested names are :optimum, :sub-optimal, and :even-less-good<br>
&lt;astearns> ack ntim<br>
&lt;fantasai> ntim: There's min, max, low, high, and optimum attributes<br>
&lt;fantasai> ntim: and value for the actual value<br>
&lt;fantasai> ntim: Depending on where value fits into the range, you get differnet colors<br>
&lt;ntim> https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meter<br>
&lt;ntim> HTML spec heuristics: https://html.spec.whatwg.org/multipage/form-elements.html#the-meter-element<br>
&lt;emilio> https://searchfox.org/firefox-main/rev/e959a4adbef21a366443993ab176f43461d38c28/dom/html/HTMLMeterElement.cpp#212<br>
&lt;ntim> UA requirements for regions of the gauge<br>
&lt;emilio> (FWIW)<br>
&lt;fantasai> ntim: There's many ways to standardize this ...<br>
&lt;fantasai> TabAtkins: Your optimum is either in min-low region, low-high region, or high-max region.<br>
&lt;fantasai> TabAtkins: if your actual value is the same region as optimum, then it's green<br>
&lt;fantasai> TabAtkins: One segment away it's yellow<br>
&lt;fantasai> TabAtkins: two segments away, it's red<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> TabAtkins: So optimal, not quite optimal, or very not optimal<br>
&lt;fantasai> emilio: I've always disliked this model<br>
&lt;fantasai> emilio: Can we make it some kind of pseudo-class that takes a percentage?<br>
&lt;fantasai> emilio: Some kind of optimality percentage?<br>
&lt;fantasai> emilio: maybe :optimum(100%) is very optimum<br>
&lt;fantasai> emilio: and you can specify inequalities<br>
&lt;fantasai> emilio: then the UA would have some selectors<br>
&lt;fantasai> emilio: For a bunch of use cases you probably actually want to use this in values<br>
&lt;fantasai> emilio: if we implemented this now, could do some kind of relative color syntax with math on the optimum value<br>
&lt;fantasai> emilio: on their own, these pseudo-classes don't seem that useful<br>
&lt;fantasai> emilio: so maybe don't standardize this, paint the meter in a neutral color<br>
&lt;fantasai> emilio: if in the future we find a way to make this nice automatically, great<br>
&lt;fantasai> emilio: the 3-state thing feels very arbitrary to me, and unlikely to be what you want<br>
&lt;fantasai> fantasai: In that case you wouldn't specify the extra attributes<br>
&lt;fantasai> ntim: You probably use progress for that<br>
&lt;fantasai> ntim: meter is for like temperature or whatever<br>
&lt;fantasai> emilio: in our implementation, optimum defaults to middle value<br>
&lt;fantasai> fantasai: If you don't specify low or high, there's only one segment.<br>
&lt;fantasai> ntim: Maybe collect use cases and see what kind of use cases would fit those best?<br>
&lt;fantasai> emilio: Does anyone use this in the wild?<br>
&lt;fantasai> TabAtkins: hard to style, so nobody does<br>
&lt;fantasai> astearns: Is it possible to do attribute comparisons and construct these selectors yourself?<br>
&lt;fantasai> fantasai: No, because you can't get the real value.<br>
&lt;fantasai> fantasai: dbaron had a proposal for virtual attributes like actual value, but never adopted<br>
&lt;fantasai> ntim: Hard because nobody uses meter right now<br>
&lt;TabAtkins> `background-color: if(style(control-value() &lt; attr(low)): red; style(control-value() &lt; attr(high)): yellow; else: green);`<br>
&lt;TabAtkins> (pretend I said `attr(low &lt;number>)`)<br>
&lt;fantasai> astearns: Another consideration is, if the base styles for meter aren't doing this kind of styling, maybe we don't need the pseudo-classes because we don't need to override anything<br>
&lt;fantasai> emilio: currently appearance: none and appearance: auto use it<br>
&lt;fantasai> emilio: But I wonder if we could realistically get rid of them?<br>
&lt;fantasai> ntim: I think there's something to be explored.<br>
&lt;fantasai> ntim: Otherwise use progress. Meter provides extra functionality.<br>
&lt;fantasai> emilio: DOM has stuff<br>
&lt;fantasai> emilio: dividing into 3 regions seems arbitrary<br>
&lt;fantasai> fantasai: usually you don't have more than 2 levels of bad<br>
&lt;fantasai> emilio: use case might be password strength meter<br>
&lt;fantasai> fantasai: Either gradient of goodness, or quantized to 2-3 colors<br>
&lt;fantasai> ntim: If you want the middle range [missed]<br>
</details>


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


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

Received on Wednesday, 1 April 2026 23:13:53 UTC