11937 2011-02-01 11:48:56 +0000 Progress element should be indeterminate if the value attribute isn't a valid float 2013-09-12 20:17:24 +0000 1 1 1 Unclassified WHATWG HTML unspecified All All RESOLVED NEEDSINFO blocked awaiting response from mounir to comment 14 (please remove this when replying) P2 normal Unsorted 1 mounir ian eoconnor ian mike public-html-admin public-html-wg-issue-tracking robin contributor oldest_to_newest 44936 0 mounir 2011-02-01 11:48:56 +0000 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." 44944 1 mounir 2011-02-01 14:00:14 +0000 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. 46033 2 ian 2011-02-25 07:59:15 +0000 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). 46052 3 mounir 2011-02-25 14:18:45 +0000 > 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. 48061 4 ian 2011-05-05 08:01:55 +0000 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. 48355 5 mounir 2011-05-09 10:44:53 +0000 (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. 48384 6 ian 2011-05-09 22:49:49 +0000 (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. 53421 7 mike 2011-08-04 05:13:42 +0000 mass-move component to LC1 80836 8 mounir 2013-01-02 16:17:47 +0000 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. 80967 9 mounir 2013-01-06 19:10:19 +0000 Re-opening, per Hixie's comment on IRC. 84150 10 ian 2013-03-08 23:52:39 +0000 > 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? 86624 11 mounir 2013-04-23 21:23:50 +0000 (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... 86913 12 ian 2013-04-26 23:36:24 +0000 Ok. Back to WONTFIX, then, unless you disagree. :-) 86935 13 mounir 2013-04-28 23:31:05 +0000 (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 87019 14 ian 2013-04-30 17:39:38 +0000 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. :-)