W3C home > Mailing lists > Public > public-html@w3.org > September 2012

[Bug 19064] New: 'input type=time' forbids legitimate use case

From: <bugzilla@jessica.w3.org>
Date: Tue, 25 Sep 2012 22:03:06 +0000
To: public-html@w3.org
Message-ID: <bug-19064-2495@http.www.w3.org/Bugs/Public/>

           Summary: 'input type=time' forbids legitimate use case
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: NE, NoReply
          Severity: normal
          Priority: P2
         Component: HTML5 spec
        AssignedTo: dave.null@w3.org
        ReportedBy: contributor@whatwg.org
         QAContact: public-html-bugzilla@w3.org
                CC: ian@hixie.ch, mike@w3.org,

This was was cloned from bug 7688 as part of operation LATER convergence.
Originally filed: 2009-09-21 17:20:00 +0000
Original reporter: Carlos Amengual <listas@informatica.info>

 #0   Carlos Amengual                                 2009-09-21 17:20:52 +0000 
input type=time has the 'max' and 'min' attributes to check the value range.
And 'min' is mandated to be lesser than 'max'. For example,

<input type="time" min="23:00:00" max="01:00:00">

would be considered non-conformant (see

However, a time of 23:00:00 is not always later than 01:00:00. For night times,
it makes perfect sense to allow times between 23h and 01h.

I suggest to add something like "When min is greater than max, UAs will assume
it to be a valid midnight-crossing interval", after the description of the min
and max attributes.
 #1   Ian 'Hixie' Hickson                             2009-09-29 07:53:34 +0000 
Interesting feature request.

I haven't added this at this time, because doing so is actually a pretty major
change to the spec (it'd involve a refactoring of the way min="" and max="" are
implemented, as well as some changes to validation, step="", and other aspects
of the spec), but I've noted it as a feature for a future version. It
definitely seems like something that would be reasonably added in the future,
and I don't see why we couldn't add it later (it's a backwards-compatible
change as far as I can tell).
 #2   contributor@whatwg.org                          2009-09-29 07:55:12 +0000 
Checked in as WHATWG revision r4034.
Check-in comment: Note the idea of <input type=time> having an allowed range
crossing midnight.
 #3   Carlos Amengual                                 2009-09-29 16:43:25 +0000 
(In reply to comment #1)
> I don't see why we couldn't add it later (it's a backwards-compatible
> change as far as I can tell).

Not sure. If the proposed change cannot be done at this time, perhaps adding
something like "authors should note that setting min>max on a form field is not
a valid way to alter form behaviour" could make sense, to avoid misuses that
could break with future changes.
 #4   Ian 'Hixie' Hickson                             2009-09-29 22:40:32 +0000 
The spec currently says:

"The max attribute's value (the maximum) must not be less than the min
attribute's value (its minimum).

If an element has a maximum that is less than its minimum, then so long as the
element has a value, it will either be suffering from an underflow or suffering
from an overflow."

...so validators will flag this as an error for now, which should help with
your concern.
 #5   Maciej Stachowiak                               2010-03-14 14:51:32 +0000 
This bug predates the HTML Working Group Decision Policy.

If you are satisfied with the resolution of this bug, 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

This bug is now being moved to VERIFIED. Please respond within two weeks. If
this bug is not closed, reopened or escalated within two weeks, it may be
marked as NoReply and will no longer be considered a pending comment.
 #6   Carlos Amengual                                 2010-04-19 10:33:36 +0000 
I did not receive any email with the text in comment #5, so could not reply in

This bug has the status of VERIFIED/LATER, hope this means that the "no longer
a pending comment" policy does not apply. At least, not in the sense that it
won't be considered in the future, as the current behaviour in the spec breaks
POLA: for example, you can filter between 22 and 23 hours, but not the next
hour between 23 and 0.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 25 September 2012 22:03:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:27 UTC