Bug 19064 - 'input type=time' forbids legitimate use case
Summary: 'input type=time' forbids legitimate use case
Status: RESOLVED LATER
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: NE, NoReply
Depends on:
Blocks:
 
Reported: 2012-09-25 22:03 UTC by contributor
Modified: 2012-09-25 22:26 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2012-09-25 22:03:05 UTC
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 http://lists.w3.org/Archives/Public/public-html/2009Sep/0832.html).

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.
http://html5.org/tools/web-apps-tracker?from=4033&to=4034
================================================================================
 #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 document:
  http://dev.w3.org/html5/decision-policy/decision-policy.html

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 time.

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.
================================================================================