11939 2011-02-01 11:55:26 +0000 <meter> (actually <progress>) � element max IDL attribute should return actual maximum value instead of reflecting the content attribute 2011-08-17 20:17:50 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED FIXED CORE-39866 P2 normal --- 12780 1 mounir ian annevk contributor ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 44938 0 mounir 2011-02-01 11:55:26 +0000 The value IDL attribute reflects the "current value" [1] which seems far more complex than the "maximum value" [2]. Reflecting the maximum value only adds one rule: if the content attribute is negative, it's returning the default value. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#concept-progress-value [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#concept-progress-maximum 44943 1 mounir 2011-02-01 13:56:24 +0000 data:text/html,<progress max='-1'></progress><script>alert(document.getElementsByTagName('progress')[0].max)</script> Opera: -1 Webkit: -1 Specs: -1 I propose to change that for 0. 46032 2 ian 2011-02-25 07:57:42 +0000 I don't follow. What problem would this solve? 46054 3 mounir 2011-02-25 14:27:33 +0000 (In reply to comment #2) > I don't follow. What problem would this solve? Actually, I would take it the other way. Why does .max reflects the content attribute when .value reflects the "current value". I think it would be more consistent to have .max reflecting the "maximum value". I agree it's not solving anything but I don't thing the current specifications makes more sense than what I propose (or solving anything...). My proposition could be more convenient in some situations. For example, you can guess the position when the progress element is determinate by doing progress.value/progress.max. 48062 4 ian 2011-05-05 08:06:44 +0000 I guess .value doesn't have to reflect the current value, we could change that to reflecting the attribute directly. Not sure why I made it more complicated. Probably no point changing that now though, since it seems interoperably implemented. Note that you never have to guess the position. Just use progress.position, which always returns the current position. 48385 5 ian 2011-05-09 22:51:16 +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: see comment 4. 48810 6 mounir 2011-05-25 15:35:27 +0000 It looks like all implementations of <meter> have IDL attributes reflecting the current value instead of the content attributes. If bug 12780 is fixed, the consistency issue raised in that bug might be more important (progress.max would be the only attributes in the meter/progress pair reflecting the content attributes and not the current value). 50667 7 mounir 2011-07-05 12:53:59 +0000 *** Bug 13139 has been marked as a duplicate of this bug. *** 50669 8 annevk 2011-07-05 13:35:56 +0000 For <progress max=0> the max IDL attribute returns 1 in both WebKit and Gecko. That is not simple reflection going on as far as I can tell. 50717 9 annevk 2011-07-06 10:22:33 +0000 Comment 1 is also incorrect. Both Gecko and WebKit return 1 for that now. 53392 10 mike 2011-08-04 05:13:25 +0000 mass-move component to LC1 55334 11 ian 2011-08-17 20:17:29 +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: Partially Accepted Change Description: see diff given below Rationale: I've tried to converge on what browsers are doing. 55335 12 contributor 2011-08-17 20:17:50 +0000 Checked in as WHATWG revision r6490. Check-in comment: track implementations http://html5.org/tools/web-apps-tracker?from=6489&to=6490