Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nullifying value on <progress /> should return component to indeterminate state #1431

Closed
steveluscher opened this issue Apr 21, 2014 · 5 comments

Comments

@steveluscher
Copy link
Contributor

Expected:

Given a <progress /> component, when its value property transitions from being a float to being null, I expect the value attribute of the <progress> tag to become unspecified, putting the control in the "indeterminate" state (the state with the animating barbershop pole pattern).

Actual:

When transitioning from being a float to being null, the value attribute of the <progress> tag becomes "0".

Test case:
http://jsfiddle.net/kb3gN/1981/

danielschonfeld added a commit to danielschonfeld/react that referenced this issue Apr 23, 2014
…/> should return component to indeterminate state.
danielschonfeld added a commit to danielschonfeld/react that referenced this issue Apr 23, 2014
… to 'value'. It seems to be the safest route to affect 'value' and therefore 'position' attributes for the progress DOM element without affecting other DOM elements which rely on the 'value' attribute and its side effects

Closes facebook#1431
@danielschonfeld
Copy link
Contributor

This is my first time contributing to the React project so it will probably take some time before they get around to giving it a more careful look and see if my proposed solution is an acceptable one.

@steveluscher
Copy link
Contributor Author

Hey @danielschonfeld. Thanks for pitching in (#1437) to try to fix this! I've left some general comments about writing code and tests in your commits.

I see that you've introduced a new attribute named propertyValue aliased to value. I'm concerned to the degree that this breaks from the standard: client programmers expect that they should be able to set the value of a DOM control by setting either the value or the valueLink property, and special-casing the <progress> element, to require that they set progressValue instead, breaks away from that.

I haven't had time to look into the problem yet, so take what I say with a grain of salt, but could it be that there's just a plain old, fixable bug, with respect to <progress> elements, indeterminateness, and the value property?

@syranide
Copy link
Contributor

Possible fix: #1510

@syranide
Copy link
Contributor

#1510 has landed in v15 and solves the underlying issue, but due to a separate issue this is not actually solved. Being tracked at #6119.

@nhunzaker
Copy link
Contributor

Looks like this issue closed:
#6119

I've just verified. This is fixed!
https://jsfiddle.net/84v837e9/120/

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants