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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19064

           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,
                    public-html-wg-issue-tracking@w3.org,
                    public-html@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
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.
================================================================================

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 25 September 2012 22:03:08 UTC