10344 2010-08-10 22:48:41 +0000 col.span, colgroup.span, textarea.cols, textarea.rows should not be limited to only non-negative numbers greater than zero 2010-10-04 14:46:10 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified Other other CLOSED DUPLICATE 10345 http://www.whatwg.org/specs/web-apps/current-work/#the-col-element P3 normal --- 1 contributor ian ayg ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 37343 0 contributor 2010-08-10 22:48:41 +0000 Section: http://www.whatwg.org/specs/web-apps/current-work/#the-col-element Comment: col.span and colgroup.span should not be limited to only non-negative numbers greater than zero. Chrome, Firefox, Opera, and Safari all agree that this alerts "false" (didn't test in IE because it doesn't support data URLs properly, too lazy): data:text/html,<!doctype html><script>var el = document.createElement("col"); var thrown = false; try { el.span = 0; } catch(e) { thrown = true; } alert(thrown);</script> Posted from: 68.175.61.233 37344 1 ayg 2010-08-10 22:51:22 +0000 Same deal for textarea.cols, textarea.rows. 38873 2 ian 2010-09-10 23:48:00 +0000 Looks like they are limited, they just don't throw (that is, the new value is ignored). Also looks like some other attributes are affected here. I guess I'll just go down all the attributes marked as limited to only non-negative numbers greater than zero and see what happens in browsers I have access to. (If anyone has access to IE, it'd be great to have info on what IE does.) 39639 3 ian 2010-09-28 01:08:09 +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: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/648 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/649 Looks like there's really not much interop in this space. What the spec says now, especially with recent changes caused by other bugs, seems like a good compromise and seems at least somewhat sane (which some of the browsers with some of the attributes really aren't). So I've left it as is. 39707 4 ayg 2010-09-28 10:07:59 +0000 Gecko treats col.span as a long, but clamped to the range [1, 1000], with default 1 (which is also used for out-of-range values). WebKit seems to treat it exactly as any long. Opera treats it as an unsigned long, which means it clamps negative values to 0 (it does this for all unsigned longs, separate bug). Gecko treats textarea.rows as a long, with setting to nonpositive values treated as setting to 0. WebKit seems to treat it as an unsigned long, but setting to nonpositive values sets to the default value (2). Opera seems to just treat it as a long. Okay, I'll grant that we have much less interop than I thought. Nobody throws, but nobody does anything that's sensible or consistent with how other values work, and browsers are often refusing to set to nonpositive values. So I guess the spec is as good as anything here. 39708 5 ayg 2010-09-28 10:12:56 +0000 Actually, this is relevant to bug 10345. DOM 2 HTML says these four attributes are signed, and you've changed them to unsigned, which you said in bug 10345 was unintentional. So is this change to the IDLs intentional or not? The requirement to throw on nonpositive values doesn't contradict any previous spec, but the IDL change does. (The IDL change does seem sensible here, just want to double-check.) 39765 6 ian 2010-09-28 17:54:47 +0000 I'll look at the IDL part of this as part of that bug. This bug is just about the way it is reflected after any IDL decision. *** This bug has been marked as a duplicate of bug 10345 *** 40006 7 ayg 2010-09-29 19:46:10 +0000 Okay, although obviously if it reverts to long, you can't say it's limited only to positive values.