This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The specs currently says: "User agent requirements: If the value attribute is omitted, then the progress bar is an indeterminate progress bar. Otherwise, it is a determinate progress bar." I think this should be changed to: "User agent requirements: If the value attribute is omitted or parsing the value attribute's value according to the rules for parsing floating point number values results in an error, then the progress bar is an indeterminate progress bar. Otherwise, it is a determinate progress bar."
data:text/html,<progress value='foo'></progress><script>alert(document.getElementsByTagName('progress')[0].position)</script> Opera: 0 Webkit: 0 Specs: 0 I think we should change that for -1 because the progress element should be considered in an indeterminate mode if @value isn't a valid foat.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: The idea is you can trivially determine what kind of progress bar it is using a simple attribute selector rule, which makes doing things like mapping bindings easier. If there's a compelling reason to do otherwise, though, please feel free to reopen the bug (you don't actually give a reason in the comments above at all).
> Rationale: The idea is you can trivially determine what kind of progress bar it > is using a simple attribute selector rule, which makes doing things like > mapping bindings easier. Oh... My current implementation is using the :indeterminate pseudo-class. It seems simpler. I should probably open a bug for that actually. > If there's a compelling reason to do otherwise, though, please feel free to > reopen the bug (you don't actually give a reason in the comments above at all). The reasons are multiple actually. First of all, it seems to make more sense to make the progress indeterminate when you can't do anything with the value. That would mean <progress value=""></progress> and <progress></progress> are different: the first is determinate and the second isn't. In addition, that way, progress.position != -1 would be a guarantee that progress @value is a number which could save a few lines of JS, I guess.
Well don't forget that all those cases where value="" is present but you're saying should be treated as indeterminate are cases where the element is invalid anyway, so authors really shouldn't be doing any of them anyway. Re :indeterminate, it seems easier to define :indeterminate just as a matter of whether an attribute is present or not than require that the UA parse the attribute to determine it. Plus, Opera and WebKit already do this... I dunno, it doesn't seem very compelling to me.
(In reply to comment #4) > Well don't forget that all those cases where value="" is present but you're > saying should be treated as indeterminate are cases where the element is > invalid anyway, so authors really shouldn't be doing any of them anyway. But they are going to do that :) > Re :indeterminate, it seems easier to define :indeterminate just as a matter of > whether an attribute is present or not than require that the UA parse the > attribute to determine it. We are already requesting that kind of stuff for :in-range and :out-of-range which only apply if min and max have a valid value. In addition, for the ease of implementation, .value is a double so it's very likely that the UA knows if the value is a valid double or not. > Plus, Opera and WebKit already do this... The progress element isn't used that much and Opera and Webkit implementations already have a few differences with the current specifications. I do not think we should worry about that. > I dunno, it doesn't seem very compelling to me. Actually, now that :indeterminate is in the specifications, I wonder why we still need the current behavior. You said it was useful to check if the progress is indeterminate but now, why is it? I do not believe changing the specs would cost anything at this point so being conservative seems worthless.
(In reply to comment #5) > > Well don't forget that all those cases where value="" is present but you're > > saying should be treated as indeterminate are cases where the element is > > invalid anyway, so authors really shouldn't be doing any of them anyway. > > But they are going to do that :) Sure, but probably not intentionally. I don't see why we'd try to second-guess what they mean here; they are as likely to want a value=0 determinate bar as an indeterminate one, IMHO. > > Re :indeterminate, it seems easier to define :indeterminate just as a matter of > > whether an attribute is present or not than require that the UA parse the > > attribute to determine it. > > We are already requesting that kind of stuff for :in-range and :out-of-range > which only apply if min and max have a valid value. In addition, for the ease > of implementation, .value is a double so it's very likely that the UA knows if > the value is a valid double or not. Granted. > > Plus, Opera and WebKit already do this... > > The progress element isn't used that much and Opera and Webkit implementations > already have a few differences with the current specifications. I do not think > we should worry about that. I do worry about it. Nobody is bug free, but adding more bugs isn't a way to get to a bug-free state. EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: > Actually, now that :indeterminate is in the specifications, I wonder why we > still need the current behavior. You said it was useful to check if the > progress is indeterminate but now, why is it? I do not believe changing the > specs would cost anything at this point so being conservative seems worthless. I don't see any value in the change you are asking for. It doesn't simplify life for authors, it doesn't simplify life for implementors, it doesn't simplify life for spec writers, and it isn't more "pure". There are no use cases for it, the cases where it would happen are all cases that are non-conforming anyway, it doesn't add any new features, it doesn't seem to solve any problems... I just don't see the point. It's not a matter of being conservative, it's just that I don't see what's wrong with what we have now.
mass-move component to LC1
I happened to came back to that bug today. I think the issue I have is that we have two default values for the "current value". The first one is when there is no @value and the second one is when @value is set to an invalid value (ie. can't be parsed as a float). It seems weird that we have two default values and AFAICT, it is not a common pattern. I think having one default value would make things simpler to understand.
Re-opening, per Hixie's comment on IRC.
> I think the issue I have is that we have two default values for the "current > value". The first one is when there is no @value and the second one is when > @value is set to an invalid value (ie. can't be parsed as a float). Both are zero, no? I mean, progress.value returns zero whether the attribute is missing or whether it has an invalid value like "foo" or "-5". What do you see as being the two default values?
(In reply to comment #10) > > I think the issue I have is that we have two default values for the "current > > value". The first one is when there is no @value and the second one is when > > @value is set to an invalid value (ie. can't be parsed as a float). > > Both are zero, no? I mean, progress.value returns zero whether the attribute > is missing or whether it has an invalid value like "foo" or "-5". > > What do you see as being the two default values? You are right. I have no idea why I wrote that...
Ok. Back to WONTFIX, then, unless you disagree. :-)
(In reply to comment #12) > Ok. Back to WONTFIX, then, unless you disagree. :-) Actually not. And sorry for wasting your time with my previous comment... We recently got a feedback from our Firefox OS frontend team that wanted to make a progress element indeterminate using `progress.value = undefined;` [1]. They said that using .removeAttribute('value') is ackward because they wanted to modify the internal state of the element, not the DOM. Given that those people are frontend developers, I believe it is an interesting feedback and maybe this use case should be considered. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=842500
Well setting .value does the same as setting setAttribute('value'), there's no internal state. :-) We could have a .indeterminate IDL attribute that returns true if the value attribute is absent and false if it's present, and when you set it to true it removes the attribute and when you set it to false it sets it to zero. Purely a convenience thing, but if you want tot implement it, I'm game. :-)