[whatwg] Please consider impedance matching <time> and datetime <input> types

[Tantek Çelik]

Summary: HTML5 provides mechanisms for both semantically inputting
datetime values (via the 6 new datetime <input> types), and
semantically outputting datetime values (via the new <time> element).
 However, the types/granularities of dates and times that are
supported do not match up on input vs output, and they should.

<input type="date">           - <time>YYYY-MM-DD</time>
<input type="datetime">       - <time>YYYY-MM-DDTHH:MM:SS</time>
<input type="month">          - not supported in current time element
<input type="week">           - not supported in current time element
<input type="time">           - <time>HH:MM:SS</time>
<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
New proposed input elements:
<input type="year">           - not supported in current time element
<input type="month-day">      - not supported in current time element

>From a design, learning/teaching perspective, it is much better if
they are made to match up, that is if every type/granularity of
datetime that can be entered can also be semantically marked up (and
vice versa).

Thus, please consider impedance matching <time> and datetime <input> types.

More details, use-cases, research here:

http://wiki.whatwg.org/wiki/Time_element#impedance_match_new_date_time_inputs

and related proposals:
* http://wiki.whatwg.org/wiki/Time_element#year_only
* http://wiki.whatwg.org/wiki/Time_element#year_month_only
* http://wiki.whatwg.org/wiki/Time_element#year_week_only
* http://wiki.whatwg.org/wiki/Time_element#month_day_only


I encourage fellow web authors and browser implementers to add their
opinions/comments to those wiki page sections.

Thanks!

Tantek



Related thread fragments from previous thread on new datetime inputs
(type="year", type="month-day") :

On Sun, Aug 8, 2010 at 6:19 PM, Ben Schwarz <ben.schwarz at gmail.com> wrote:
> While creating an input that works for every use case you can think of
> sounds like a good idea, I'd like to question weather a user would ever
> enter a date that would require the inclusion of BC/AD.
> ...
> I'm certain that there is a requirement to markup such text,

It would be great if you could add your +1 accordingly to allowing
<time> to markup just a year:

http://wiki.whatwg.org/wiki/Time#year_only


> but as for
> entry I'm strongly of the opinion that you're over cooking this.

That may be.  My goal with these 2 additional datetime inputs (to the
current 6, thus making 8 total) was to not to be comprehensive but to
"fill out" what seemed to be a relatively similar set of datetime
inputs in terms of frequency of actual use cases.


On Sun, Aug 8, 2010 at 7:20 PM, Ben Schwarz <ben.schwarz at gmail.com> wrote:
>
> ...
>
> Given that one of the principals of HTML5 is to have a well designed product
> that is easily understandable, I'd prefer to follow the path of simplistic,
> minimal design.

Ben, I tend to agree with those design principles.  In this case the
only reason I proposed those two additional input types (year,
month-day) is that they seem to naturally fit in with the existing 6
(month, week, date, datetime, datetime-local, time) and in seem just
as practically useful, if not more so, e.g. I see a lot more obvious
use-cases for the new input type=year as compared to the existing
input type=week for example.


> Not one where every example found will be implemented—I'd like to think that
> a browser vendor would find it very difficult to schedule the time to
> implement such a full featured method of handling every date representation
> known to man, rather than "other awesome feature x".

Of course, and I tend to agree with your general analysis/reasoning.

Frankly, doing a good job on the existing 6 datetime inputs in general
is quite challenging/difficult, even with the progress/designs that
Opera and Safari have put forth.

However, from a design (visual, interactive) perspective, the 6
existing datetime inputs cover a sufficient diversity of cases that
if/when you (e.g. a browser implementer) do implement them, it's
pretty obvious/easy how to implement the 2 additional ones I've
proposed as variants.

I deliberately proposed adding input type="year" and input
type="month-day" both because of their utility/use-cases and
*specifically* because the marginal implementation cost of adding them
to the existing 6 is quite small in comparison to the marginal benefit
of said use-cases.



On Mon, Aug 9, 2010 at 7:10 AM, Daniel Glazman
<daniel.glazman at disruptive-innovations.com> wrote:
>
> Tantek needs a year. He never said he needs to specify in
> which system the year is counted. He never said he cannot use
> a radiobutton for BC/AD or any other calendaring system
> aside of the year input.
>
> Why make things complex when it's possible to make them simple?

Right, I am ok with simply incrementally adding input type="year" and
type="month-day" within existing calendar/datetime constraints
(Gregorian assumption etc.) I believe the existing documented
use-cases justify this small addition.

Whether or not we explore additional calendaring systems (and their
use-cases) is perhaps worthy of its own thread.  I think it has
sufficient potential to at least deserve additional
research/consideration.


-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5