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 position IDL in progress element[1] is not necessary, since authors/developers already have both value and max attributes in DOM (position is basically = value/max -- when both max and value are defined). Being read-only, it contributes almost nothing. Since position represents the percentage of progress completion (between 0.0 and 1.0), another option would be to drop the read-only constraint on the position IDL and oblige user agents to compute and update the respective value when setting a given position. In that case, if the progress bar was an indeterminate progress bar, UAs might ignore changes to position attribute. [1] http://dev.w3.org/html5/spec/Overview.html#dom-progress-position
Just as a reference, other implementations of progress bars, such as XUL[1] and Windows Forms[2], has no property such as "position". For instance, in one that has a similar approach, Java Swing, the JProgressBar only has a method called getPercentComplete, which led me think that besides almost useless, the position IDL as it is specified today may be misleading, because the term "position" in web development context also refer to the position of the element in the page (as in CSS property). Thus, if progress.position will continue to exist in the spec., I'd suggest at least changing its name to "percent" or something similar.
Forgot to include the links: [1] https://developer.mozilla.org/en/XUL/progressmeter [2] http://msdn.microsoft.com/en-us/library/system.windows.forms.progressbar.aspx JProgressBar: http://download.oracle.com/javase/7/docs/api/javax/swing/JProgressBar.html
mass-move component to LC1
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: While authors do technically have access to both value and max, it's not always particularly convenient to get the exact values being used. The .position attribute gives authors a trivial way of finding the position. It's not "percent" because it's a value in the range 0..1, more properly described as a position.
If it is a matter of convenience, why is it read-only then? It would be pretty convenient if the author could change the "position" of the progress bar without having to access the values of "value" and "max". The author that accesses the "position" is the same that changes it, so it is contradictory to say that it would be convenient if the authors will still have to use "value" and "max" anyways. In regards to the term "percentage", it is valid, since the range 0...1 represents a percentage from 0% to 100%, which is the range of a progress bar. 100% is 100/100, which is 1. I don't understand your point. My point, however, is that the term "position" is misleading and does not properly describe the range "0...1" whatsoever. Anything else like "percentage", "completion" or whatever you want to call it would be better for the reasons I already explained.
Can you give an example of a use case where you would want to _set_ the value as a fraction yet still want an explicit value and max? Regarding the name: I don't agree that percentage is better than position, nor that completion is. It's not a percentage if it's not out of a 100 (which it isn't, it's a fraction 0..1). The progress bar is not a percentage; almost always the max will be some number other than 100, e.g. in a file transfer it would be the file size, in a long calculation it would be the number of steps, etc. The term "position" is the right term of art here; see e.g. reference [2] in comment 2 which refers to the position of the progress bar in the documentation.
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: Did Not Understand Request Change Description: no spec change Rationale: see comment 6
Sorry for the very late response, I couldn't follow up the bug. > I don't agree that percentage is better than position, nor that completion is. > It's not a percentage if it's not out of a 100 (which it isn't, it's a fraction > 0..1). The progress bar is not a percentage; almost always the max will be some > number other than 100, e.g. in a file transfer it would be the file size, in a > long calculation it would be the number of steps, etc. Completely disagree. The position is a number between 0..1, which may represent a percentage (0% to 100%) whether the max is 100 or not. 100% = 100/100 = 1. > The term "position" is the right term of art here; see e.g. reference [2] in > comment 2 which refers to the position of the progress bar in the > documentation. Also disagree. In reference [2], the term "position" refers to the absolute position (or the Value attribute in our case), i.e., if max=200 and value=100 the position as specified in [2] is 100, not 0.5 (or 50%?), which is the case of our "position". Thus, for me, the term of art "position" that you refer to is the absolute position and, in the specification, it is actually a relative position. See http://en.wikipedia.org/wiki/Relative_change_and_difference [4]
A percentage is a value out of a hundred. A value out of 1 is generally called a fraction. As far as I can tell, the term "position" doesn't appear in [4]. In [2], the term "position" is used to describe what is set by changing the value. It's not the same thing as value itself, which is the number between 0 and the maximum; it's the physical position of the bar, which can be described as a fraction from 0 to 1.
I think we're not reading the same thing on [2], because that's what I read on "value" and "step" attributes: Value Gets or sets the current position of the progress bar. Step Gets or sets the amount by which a call to the PerformStep method increases the current position of the progress bar. If you read the term position above with the same meaning as in the current spec, never mind - I couldn't read that. I wish I could see the term "position" with same meaning used in the spec in any other implementation of a progress bar out there, but I couldn't find. If you think the spec is not creating new terms for a UI control that was vastly implemented before, just close the bug. Adding some resources that don't use "position": [5] Android ProgressBar (don't have such 0..1 attribute) http://developer.android.com/reference/android/widget/ProgressBar.html [6] iOS ProgressBar (use progress for HTML5's position) http://developer.apple.com/library/IOS/#documentation/UIKit/Reference/UIProgressView_Class/Reference/Reference.html
(In reply to comment #10) > I think we're not reading the same thing on [2], because that's what I read on > "value" and "step" attributes: > > Value Gets or sets the current position of the progress bar. > Step Gets or sets the amount by which a call to the PerformStep method > increases the current position of the progress bar. In this API, value is the number from min to max. Changing the value thus sets the position, which is the fraction of the bar that is filled. I don't question that there are APIs that don't use "position". 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: No argument was presented for describing why you would want to change the position directly rather than through the value; the feature is a convenience API that allows authors to expose the current state in other manners trivially (e.g. as a percentage just by multiplying by 100 and truncating appropriately), and no argument was presented for why this is a bad thing to provide; and regarding the name, "position" seems like the best term suggested so far.