Meter element states

[lukewarlow]

I raised an issue in the csswg but it feels like it'd be good to discuss here too.

To be able to style a meter element we need some way to style based on how optimal the value of the meter element is.

WebKit (and blink) uses different pseudo elements and their naming is ::-webkit-meter-even-less-good-value, ::-webkit-meter-suboptimum-value and ::-webkit-meter-optimum-value.

Firefox has a single ::-moz-meter-bar pseudo element and instead applies pseudo classes to <meter> these are :-moz-meter-sub-sub-optimum, :-moz-meter-sub-optimum and :-moz-meter-optimum.

It would be good for us to discuss which of these approaches is more appropriate and to bikeshed names.

There's also an interop issue between WebKit/Blink and Gecko on the algorithm for determining these states. Which we should fix too.

[lukewarlow]

As these are different states rather than inherently different structured elements pseudo classes seems the correct approach (though it's possible I'm missing a use case that WebKit allows that Firefox doesn't).

I suspect we can drop the meter prefix and just go with something like :sub-sub-optimum, :sub-optimum, :optimum? But naming would need bikeshedding as neither Firefox's nor WebKit's seem great.

Here's a demo of a custom element I've made to demo what this would look like: https://codepen.io/lukewarlow/pen/mybPqja

Regarding the interop issue my intuition is that Firefox's behaviour is better, and fwiw chatgpts interpretation of the spec text matches Firefox's. Though for simplicity changing Firefox to match WebKit and chrome might just be easiest.

[mfreed7]

I vote for :meter-value-is-less-good-than-the-not-quite-perfect-value-at-least-for-now

[css-meeting-bot]

The Open UI Community Group just discussed Meter element states, and agreed to the following:

• RESOLVED: Meter element states should be represented using pseudo-classes.

The full IRC log of that discussion

<hdv> lwarlow: not sure if any of you styled meter elements… it is not a fun time
<hdv> lwarlow: there's a draft spec on standardising pseudo elements for the range input.
<hdv> lwarlow: we can probably make it work for progress and meter too
<hdv> lwarlow: for switch and range, once the structure is done we have everything we need to do styling. With appearance base
<masonf> For those interested: https://drafts.csswg.org/css-forms/
<hdv> lwarlow: for progress, there's the indeterminate state you can style based on. The tricky one is the meter element
<hdv> lwarlow: there's 3 different states it can be in
<hdv> lwarlow: webkit and blink use different pseudo elements, Firefox has a single pseudo element and uses pseudo classes instead
<bkardell_> q+
<hdv> lwarlow: discussion is… which approach we think is best? I personally feel Firefox'es is
<hdv> lwarlow: there's also an interop bug where the browsers don't agree on calculation of the states
<bkardell_> q-
<hdv> masonf: so Q1 is should there be pseudo classes or pseudo elements, and Q2 is what would be their names?
<bkardell_> q+
<hdv> masonf: we can probably resolve on pseudo classes
<hdv> masonf: rather than pseudo elements
<masonf> ack bkardell
<lwarlow> Proposed Resolutions: Meter element states should be represented using pseudo-classes.
<hdv> bkardell_: I'm confused. What do you want to make pseudo classes?
<hdv> lwarlow: the value attr of the the meter element has min, max, high and optimum, based on combo of these, the value can be below or optimum … to be able to style that you need some way to get that state
<hdv> lwarlow: does exist in Firefox, doesn't easily exist in other engines
<hdv> masonf: any objections to saying these are pseudo classes not pseudo elements?
<scott> q+
<lwarlow> RESOLVED: Meter element states should be represented using pseudo-classes.
<masonf> ack scott
<hdv> scott: in 2018 I was doing a bunch of tests on meter and progress elements… noticed at the time, if you provided custom styles to either element it would completely mess up the accessibility tree for them, depending on the browser
<hdv> scott: let's watch out for it
<hdv> masonf: do you know if it is still the case in any browser?
<hdv> scott: not sure
<hdv> lwarlow: I believe the ansser is still broken
<hdv> s/ansser/answer
<hdv> masonf: sounds like bugs we should fix
<masonf> q?
<hdv> masonf: shall we kick off the naming discussion?
<bkardell_> async sounds good
<hdv> lwarlow: can also do it async
<hdv> lwarlow: fwiw my intuition is FF is correct
<hdv> masonf: what's the TLDR?
<hdv> lwarlow: when your value is the same as one of the boundaries, chrome and webkit use an exclusive range, whereas firefox uses an inclusive range… I made a demo where it's optimum in webkit but sub optimum in firefox
<hdv> masonf: we should fix this as well as the accessibility issues
<hdv> masonf: let's leave the naming thing to the issue and folks can come back to the issue to fix

[mfreed7]

Reminder: the still-open agenda item for this issue is to brainstorm better names for the pseudo classes. Note the rules for meter coloring at least according to the spec. Per that text, there are three different regions you can be in: the "optimum" region, the "sub-optimum" region, and the "even less good" region (yes this is the spec wording). The way you get "even less good" is when the optimum attribute is lower than the low or higher than the high, then the region at "the other end" is considered "even less good".

With that in mind, here are the pseudo classes I've heard mentioned:

• :sub-optimum
• :suboptimum-value
• :even-less-good-value
• :optimum-value.
• :sub-sub-optimum
• :sub-optimum
• :optimum

What else can people think of?

[lukewarlow]

:worst, :medium, :optimum or something along those lines maybe? I wonder if any design systems have the meter concept and if they do have then what names do they use?

[sorvell]

:optimal-range, :less-optimal-range, :least-optimal-range

The word "range" makes clear the styling applies to a region and not just a specific point. The term "optimal" is used instead of "optimum" because optimal can be an adjective but optimum is not. If matching the attribute is preferred, this could just be optimum-*.

[lukewarlow]

Yeah the linguistics part of me very much prefers optimal rather than optimum so if we don't need to match the attribute name that'd be my preference.

[css-meeting-bot]

The Open UI Community Group just discussed Meter element states, and agreed to the following:

• RESOLVED: we think it should include a term that as unambiguously as possible describes that this is some kind of area, region, range, etc., but not pick those exact words.

The full IRC log of that discussion

<bkardell_> masonf: first is specifically about pseudo classes - the only open question, I think, is about naming
<bkardell_> masonf: there are "sub optimum" and "less good" , various options
<bkardell_> masonf: one set has range in them - not sure if that is a good or a bad pattern wrt CSSWG
<bkardell_> masonf: thoughts?
<brecht_dr> q+
<masonf> ack brecht
<bkardell_> scoot: I don't care so much as long as they are consistent
<bkardell_> brecht_dr: There is a point to range - I think that person is onto something there.
<bkardell_> masonf: oh I guess the confusion I had was it was not a range element it was a meter element
<bkardell_> brecht_dr: maybe "optimal range" or "optimal region" - both are overloaded. landmarks are also sometimes referred to as region. But I do like the general idea of a second word
<bkardell_> masonf: even in my original reading I was confused a little about whether optimum was within the range that includes optimal... I think I agree with that
<bkardell_> masonf: inclined to say we haven't even gotten the best ones yet, maybe we keep brainstorming on the thread
<bkardell_> brecht_dr: agree, but maybe you could say what parts you do agree to
<bkardell_> masonf: maybe we could resolve on something about including names that correspond to a range or a region of the...?
<masonf> proposed resolution: the names should include some notion that it is a "range" or "region", to make that concept clear.
<bkardell_> -1
<bkardell_> brecht_dr: It could help, I always remind myself when I am looking through my code
<masonf> bkardell_: both those words are overloaded, range region etc, you could say multiple times - there is a range element, text range, etc.
<masonf> bkardell_: maybe those are the best, but let's not resolve on those specifically. Area might be better.
<masonf> bkardell_: if we want a resolution, it should say that we think it should include a term that as unambiguously as possible describes that this is some kind of area, region, range, etc., but not pick those exact words.
<brecht_dr> +1
<masonf> RESOLVED: we think it should include a term that as unambiguously as possible describes that this is some kind of area, region, range, etc., but not pick those exact words.