Skip to content
This repository was archived by the owner on Jul 30, 2019. It is now read-only.

[question] about rules of setting max attribute after setting value in <progress> element #1024

Closed
Jinjiang opened this issue Sep 22, 2017 · 3 comments
Assignees
Labels
Milestone

Comments

@Jinjiang
Copy link

As https://w3c.github.io/html/sec-forms.html#the-progress-element says:

if the parsed value was greater than or equal to the maximum value, then the current value of the progress bar is the maximum value of the progress bar.

So in demo https://jsfiddle.net/r5gohw4w/
If we set 50 to value first (before setting 100 to max), the current value (50) is greater than the maximum value (1.0). So the current value will be set as 1. And then we set 100 to max so at the end the position of the <progress> element should be 1/100.

Is that correct? But in Safari & Chrome it always be 50/100.

Thanks.

@chaals
Copy link
Collaborator

chaals commented Sep 24, 2017

Interesting - it depends when the normalisation step happens. Firefox behaves like blink - but Edge does the normalisation so you get 1/100 - which seems like it is actually correct according to spec.

@travisleithead @bzbarsky @hober @cynthia should we normalise the common behaviour... which would mean filing a bug on Edge and specify timing for how clamping values happens, or should we try to change the others to match what the spec seems to say and then clarify what in the spec meant it wasn't implemented like that?

@chaals chaals added the bug label Sep 24, 2017
@bzbarsky
Copy link

Fwiw, the Gecko implementation is that the clamping happens when you ask. That is, the "current value" is not actually stored anywhere; it's just computed when someone (like layout) needs it.

All that said, the spec as currently written is nonsensical, imo, and the Edge behavior is inconsistent (which is good). If Edge were consistent, it would render <progress max=100 value=50> and <progress value=50 max=100> differently, which is not what anyone wants.

I would argue that similarly no one wants the linked demo to behave as it does in Edge. Order in which attributes are set really should not affect the resulting state; any time it does that's a bug in the platform.

@chaals chaals self-assigned this Dec 14, 2017
@chaals chaals added this to the HTML5.3 WD1 milestone Dec 14, 2017
chaals pushed a commit that referenced this issue Jan 30, 2018
Fix #1024

* make "in/determinate progress bars" (which were used as terms) a
proper defined term
* refactor to gather requirements accordingly

Hopefully clarify sufficiently that the behaviour depending on attribute
order in source is obviously a bug.
@chaals
Copy link
Collaborator

chaals commented Jan 30, 2018

(In passing, note that Firefox presents <progress value="a"></progress> visually as completed, which is inconsistent with the spec and what it does in JS, setting value to 0.)

LJWatson pushed a commit that referenced this issue Jan 31, 2018
Fix #1024

* make "in/determinate progress bars" (which were used as terms) a
proper defined term
* refactor to gather requirements accordingly

Hopefully clarify sufficiently that the behaviour depending on attribute
order in source is obviously a bug.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants