*** Bug 9914 has been marked as a duplicate of this bug. ***

Also width on HTMLPreElement, and rowSpan/colSpan on HTMLTableCellElement, and hspace/vspace on various interfaces other than HTMLImageElement, and span on HTMLTableColElement, and cols/rows on HTMLTextAreaElement.  Those are all the ones I can see.

What are they in implementations though? That is what matters.

They're signed long in Gecko.  See discussion:

https://bugzilla.mozilla.org/show_bug.cgi?id=586126

There are a number of other unsigned long attributes; the bug you linked to mentions that Gecko only has four. Are you sure the ones you mentioned are the only ones that need changing?

(The differences from DOM2 are completely unintentional; I just assumed these were unsigned instead of checking when I added them. My bad.)

I think those are all the cases for reflected attributes, yes.  IIRC, I used my reflection test suite to get the list in comment #2 (just seeing which tests Gecko failed), so I didn't look for other places where the types didn't match.

(I mean, I looked for where Gecko failed and then confirmed that there was indeed a mismatch between HTML5 and DOM 2 HTML, I didn't just assume that Gecko must be right.  I did implicitly assume that Gecko doesn't match HTML5 anywhere that HTML5 disagrees with DOM 2 HTML, so if that's wrong the list might be incomplete.)

*** Bug 10344 has been marked as a duplicate of this bug. ***

Given:
   http://www.hixie.ch/tests/adhoc/dom/webidl/attributes/
   http://krijnhoetmer.nl/irc-logs/whatwg/20090714#l-102
...I'm not really sure what it means, in practice, for an attribute to be signed or unsigned, from a historical perspective.

Given how bad the interop is here, I think it might be better to just go with sanity, which the spec, IMHO, is closer to than most browsers. In particular, I'm not sure Gecko's behaviour here is necessarily more sensible than any other browser's. They're all pretty nutty.

However, I am very open to changing the spec here, if we know what we want to change it _to_. It's not clear to me that DOM2 HTML is any more sensible (or closer to interop) here than what we have here in DOM5 HTML.

Any opinions?

Maybe we should WONTFIX this overall bug and just consider changes on a per-attribute basis?

Behavior when giving negative values for this sort of attribute is all over the place.  Some browsers clamp, some browsers wrap, some ignore out-of-range values, some do one thing sometimes and another thing other times.  The current spec seems sane to me: make them unsigned longs in the interface, and unsigned longs ignore out-of-range values in content attributes.  And the ones we don't want to be 0 also ignore a content attribute of 0.  (Not so sure about the reasonableness of throwing exceptions on IDL set, though, unless that consistently happens on out-of-range IDL sets.)

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:

Ok.

As per the discussion above, I'm rejecting this bug on the principle that in general we want the types to represent roughly what the allowed ranges are for the IDL attributes.

It's almost certainly the case that:

 * some IDL attributes have the wrong types, given this definition
 * the "reflection" rules are wrong, either on specific aspects (e.g. raising exceptions on certain cases), or for specific attributes (e.g. maybe some attributes need particular weird behaviours for compat).
 * some attributes have the wrong ranges.

Please file specific bugs if there are specific concerns like this. In particular there are three rationales that are IMHO strong here:

 1. Specific pages require specific behaviour (legacy content compatibility). Please cite URLs so I can look into what the constraints are when filing such bugs.

 2. What the spec says is illogical, and no known specific compatibility constraints exist, and there is no wide interop, so we can probably change the spec to be more logical.

 3. All (or most) of the browsers do the same thing on a specific case that the spec disagrees on.