<meter> rendering for case min == max

# Mikko Rantalainen (6 days ago)

According to html.spec.whatwg.org/multipage/form-elements.html#the-meter-element following inequalities must hold for <meter>:

minimum ≤ value ≤ maximum minimum ≤ low ≤ maximum (if low is specified) minimum ≤ high ≤ maximum (if high is specified) minimum ≤ optimum ≤ maximum (if optimum is specified)

This (and other prose) allows for following element

<meter min=0 value=0 max=0>Nothing to be done</meter>

jsfiddle.net/zx5xesg6

However, rendering engines (at least Blink and Gecko) disagree on rendering of such an element. Blink renders this as an empty meter and Gecko renders this as an full meter.

I'm slightly balanced for rendering this as full meter (Gecko style) because I would guess such meter is usually displaying some kind of progress ("total number of items completed for this exam") and if nothing is to be done, the meter should be full. Another choice would be to make this even more similar to <progress> which already handles

similar situation similarly between different user agents.

The spec should specify one way or the other for this corner case.

Contact us to advertise here
# Anne van Kesteren (6 days ago)

On Mon, Mar 19, 2018 at 11:13 AM, Mikko Rantalainen

<mikko.rantalainen at peda.net> wrote:

The spec should specify one way or the other for this corner case.

Agreed, we're tracking this in whatwg/html#3520. If anyone would like to help clarify the prose in the form of a pull request or wants to make a strong case for Firefox's behavior, that'd be much appreciated.

# Roger Hågensen (7 hours ago)

On 2018-03-19 12:49, Anne van Kesteren wrote:

On Mon, Mar 19, 2018 at 11:13 AM, Mikko Rantalainen

<mikko.rantalainen at peda.net> wrote:

The spec should specify one way or the other for this corner case.

Agreed, we're tracking this in whatwg/html#3520. If anyone would like to help clarify the prose in the form of a pull request or wants to make a strong case for Firefox's behavior, that'd be much appreciated.

Is it possible the Firefox devs assumes that 0,0,0 infers this to be a "unknown" progress state? On Windows UI this tends to be shown as a a full but "pulsing" progress bar, in a looping animation. But I've seen UI design that also fills up the progress then clears it, in a looping animation.

Thouigh one could easily "animate" this via just setting the values, so even if 0,0,0 was speced to always show nothing one could still do the "unknown"! behaviour.

Personally I think 0,0,0 should not only be empty but the actual progress bar itself should not be drawn as it's in a non-state if you know what I mean. Which probably will be changed by some javascript moments later.

Treat 0,0,0 as it being there but just non-visible maybe?

Although I'm almost tempted to say that 0,0,0 should throw a warning in the dev console log that a valid range must be set and that the value must be within (inclusive) that range.

Want more features?

Request early access to our private beta of readable email premium.