See HTML5 spec section 4.10.4.2.9. This encompasses parsing the min and max attributes, hooking them to the rangeUnderflow() and rangeOverflow() methods on the ValidityState object, and adding :in-range and :out-of-range support. There is existing support for some WebKit-custom syntax for similar things for Dashboard widgets; this syntax predates HTML5. dhyatt says that this syntax will be deprecated, and we don't need to worry about hooking this existing machinery into the ValidityState object or CSS selectors.
On http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#rules-for-parsing-floating-point-number-values there's the algorithm to parse element's value and check whether or not it's a float number value. Is that somehow already implemented?
(In reply to comment #1) > On > http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#rules-for-parsing-floating-point-number-values > there's the algorithm to parse element's value and check whether or not it's a > float number value. > > Is that somehow already implemented? WTF::strtod() in JavaScriptCore/wtf/dtoa.h might be useful.
(In reply to comment #2) > WTF::strtod() in JavaScriptCore/wtf/dtoa.h might be useful. Thanks man, it's a good starting point.
I'll split this bug into 3. They will be: - min/max and ValidityState.rangeOverflow rangeUnderflow support for type=number - ditto for date&time types - :in-range and :out-of-range CSS selectors
Kent, did anything ever happen on this?
(In reply to comment #5) > Kent, did anything ever happen on this? min/max attribute support was done. The remaining is :out-of-range and :in-range CSS selectors. It's easy to implement but my priority for it is low.
OK, updating title.
It already has a dedicated bug: Bug#29071.
OK, you could have just marked as a dupe then. *** This bug has been marked as a duplicate of bug 29071 ***