So you're saying that it should apply to all of:

<input type=number max="4711">
<input type=number min="4711">
<input type=number min="17" max="4711">

but not apply to any of:

<input type=number>
<input type=text max="14">
<input type=date>
<input type=time>

?

(In reply to comment #1)
> So you're saying that it should apply to all of:
> 
> <input type=number max="4711">
> <input type=number min="4711">
> <input type=number min="17" max="4711">

Yes.

> but not apply to any of:
> 
> <input type=number>
> <input type=text max="14">
> <input type=date>
> <input type=time>

I agree for <input type='text' max='14'> for the others, those types can be limited (min and max apply to them). My original comment ask to have the pseudo-classes always applying to number, range and date/times types (even if min and max isn't present). I wouldn't disagree to have them apply only if min or max is present but in that case, what should we do if min or max isn't valid? (<input type='number' max="foo"> for example).
I think it's easier to understand and implement to have these pseudo-classes applying to some types instead of applying for some types if a specific attribute is present and valid.

To me it seems most consistent to have them apply only if there in fact is a range.

While it's more common to talk about ranges of numbers, in database contexts it's quite common to talk about ranges of strings. For example you can request all records between "a" and "c" which would include "aa" and "azzz", but not "d".

So I think it's most consistent if the classes apply only if an actual range limitation is imposed on the submitted value. Which would mean for:

<input type=number max=4711>
<input type=date min="1987-06-06">

but not for any of

<input type=number>
<input type=number max="foo">
<input type=date min="yesterday-ish">

I would be fine with that too but I'm wondering how is that more consistent? I mean, is there anything similar in HTML/CSS specs?
The closest thing I see is :valid/:invalid but we can't really use it for consistency because of setCustomValidity() that can make any element invalid.

It just seems more consistent to me that the range selectors only apply if there is an actual range requirement.

If you want them to apply "when there could be ranges" you get into the somewhat fuzzy discussion of which types can have ranges.

I think the input types that can have ranges are those that can have min and max applying.
But, to be clear, I'm fine with your proposition. It seems more complex than just doing it per-type but it also makes more sense (at least, the logic is more strict).

More complex in what sense? To implement or to use? If it's the former then that doesn't worry me so much. Unless you think it's prohibitively complex (e.g. perf). You're likely the one to implement in gecko, so you're the best judge of that ;-)

Both actually.
That would be the first pseudo-class I see that applies or not depending on so much conditions (has to be <input>, with type={number,range,...}, with max or min defined and set to a valid value, then depending on the element's value, one of the two classes will apply). But I'm far from being experienced on that field so I trust your judgment.
For implementation, the real issue is the min/max validity which can't be checked too often so depending on the UA, it might be more or less a pain. For Gecko, we will have to keep a flag telling us if those attributes have valid values for the current type.

I'm not sure I agree that it's that many conditions. Conceptually it's just one condition, "has a defined range". What you are proposing is "is of type that supports ranges" which IMHO isn't obviously a simpler condition.

Additionally, the :-moz-ui-invalid pseudo classes we have in gecko have a much more complex set of conditions, though there too the concept is the simpler "does it make sense to render invalid-UI".

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 tightened up the definitions to match CSS3 UI more closely (which basically means I did what Jonas suggested).

Checked in as WHATWG revision r6106.
Check-in comment: Make :in-range and :out-of-range definitions match the spec that introduced them.
http://html5.org/tools/web-apps-tracker?from=6105&to=6106

mass-move component to LC1