Closed fbender closed 11 years ago
I would argue that Firefox does not properly support :in-range and :out-of-range simply because they do not support form elements that result in an out-of-range state.
A min and max only applies to date, time, number and range fields. Firefox only supports range fields at this time. But the spec says it the useragent must clamp the value between the min and max for range fields. This will mean that the value will be by definition always in range.
Judging by the Bug I mentioned, they have elements that support in-/out-of-range, namely XForms stuff. Your point is kind of valid if you only take HTML5 into account (which in part builds upon XForms).
Either way however, you're doubly punishing Gecko (and others) here because you are also checking for e. g. input[type=number]
. Also, on css3test.com Firefox passes the in-/out-of-range test so there is a way to check for these without tying the check to an HTML5 input element check.
Given that this is HTML5test, I do not think it is unfair to judge this selector based on HTML5 form fields.
What css3test.com does is nothing more than see if using the selector results in an error or not. This basically checks for parsing errors. It does not check to see if it actually gives the correct result. It's a valid test in itself, but not if you want to see if this selector actually works on HTML5 form fields.
I think the practical approach is the best one. It is not about whether or not a browser 'in theory' supports this selector, but if it is actually usable. In Firefox it is not.
Both :in-range and :out-of-range are supported since Gecko 1.8 (I think used in Firefox 3.0 or 3.5), see Bug 302462. The tests on HTML5Test.com however fail in current Firefox versions.