This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10344 - col.span, colgroup.span, textarea.cols, textarea.rows should not be limited to only non-negative numbers greater than zero
Summary: col.span, colgroup.span, textarea.cols, textarea.rows should not be limited t...
Status: CLOSED DUPLICATE of bug 10345
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-10 22:48 UTC by contributor
Modified: 2010-10-04 14:46 UTC (History)
5 users (show)

See Also:

Attachments

Description contributor 2010-08-10 22:48:41 UTC 
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
Comment 1 Aryeh Gregor 2010-08-10 22:51:22 UTC 
Same deal for textarea.cols, textarea.rows.
Comment 2 Ian 'Hixie' Hickson 2010-09-10 23:48:00 UTC 
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.)
Comment 3 Ian 'Hixie' Hickson 2010-09-28 01:08:09 UTC 
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.
Comment 4 Aryeh Gregor 2010-09-28 10:07:59 UTC 
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.
Comment 5 Aryeh Gregor 2010-09-28 10:12:56 UTC 
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.)
Comment 6 Ian 'Hixie' Hickson 2010-09-28 17:54:47 UTC 
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 ***
Comment 7 Aryeh Gregor 2010-09-29 19:46:10 UTC 
Okay, although obviously if it reverts to long, you can't say it's limited only to positive values.