[whatwg] [WF2] <format> Element III - The <date> Supremecy

[Matthew Raymond]

    I've recently come up with a new idea for date and time controls 
that abandons <input> entirely. It's base partly on the <date>, <time> 
and <datetime> elements I specified in earlier messages.

    As with our previous model for the <date> element, so long as the 
contents are ISO8601, you can express a static date like this:

| <date>2005-01-30</date>

    ...Which would, of course, be rendered inline with any accompanying 
text. If the contents aren't ISO8601, you'd simple assign a |value| 
attribute:

| <date value="2005-01-30">01/30/2005</date>

    Here's where we make a hard left turn into the Twilight Zone. 
Suppose, simply by adding a special <submit> child element, you can turn 
mild mannered <date> into a full-blown date control:

| <label>Event Date: <date><submit name="date">2005-01-30</date></label>

    So if you wanted a date control with ISO8601-compliant fallback 
content, you'd do this:

| <label>Event Date:
|  <date value="2005-01-30">
|   <submit name="date">
|   <input name="date" value="2005-01-30"><br>(Format: yyyy-mm-dd)
|  </date>
| </label>

    Now, let's suppose you want to submit to the server in a non-ISO8601 
format. Then you'd use the |format| attribute of the <submit> element to 
define the format for submission:

| <label>Event Date:
|  <date value="2005-01-30">
|   <submit name="date" format="%m/%d/%Y">
|   <input name="date" value="01/30/2005"><br>(Format: mm/dd/yyyy)
|  </date>
| </label>

    Ah, but what if the server is expecting input from three <select> 
controls instead of one textbox? They, you'd need to use multiple 
<submit> elements:

| <label for="date">Event Date:</label>
| <date id="date" value="2005-01-30" min="2005-01-25" max="2006-01-25">
|  <submit name="month" format="%m">
|  <submit name="day" format="%d">
|  <submit name="year" format="%Y">
|
|  <select name="month"><!-- Option elements. --></select>
|  <select name="day"><!-- Option elements. --></select>
|  <select name="year"><!-- Option elements. --></select>
| </date>

    Each <submit> above is sent to the server as if it were from a 
separate control, so you can easily tailor <date> to eliminate the need 
for server script changes.

    If you want the user to choose from a list of dates, just use the 
|list| attribute:

| <label>Event Date:
|  <date list="datelist"><submit name="date" format="%m/%d/%Y"></date>
|  <datalist id="datelist">
|   <select name="date">
|    <option selected>01/30/2005</option>
|    <option>01/30/2005</option>
|    <option>01/30/2005</option>
|   </select>
|  </datalist>
| </label>

    The <date> element will automatically convert the various <option> 
elements to ISO8601 based on the |format| attribute of the first 
<submit> element.

    Note that this will work for "time" and "datetime" as well. For example:

| <label>Event Time:
|  <time id="time" value="19:00:00.0Z" step="1 minute">
|   <submit name="time" format="%I:%M %p">
|   <select name="time"><!-- Option elements. --></select>
|  </time>
| </label>

PROS:
* A single element is used for all dates/times in all circumstances.
* Near perfect graceful degradation, especially when you want multiple 
legacy controls.
* Submission formatting for the server is highly flexible, eliminating 
the need for changes to the server to accommodate WF2 in most cases.

CONS:
* Not quite as simple as <input type="date">.
* Some redundant data.
* The <label> element is a real pain when you want it to work for both 
the <date> element and a legacy control.

    That last part really bugs the heck out of me. The problem isn't so 
much how <label> is defined in HTML so much as how the |id| attribute 
is. If I read HTML 4.01 correctly (and the problem is probably similar 
in XHTML), you can only have one distinct |id|, even if the |id| is part 
of an element's fallback content. For instance, if you have an <object> 
with id="ob1", any element inside it must have a different |id|, 
regardless of the fact that the <object> wasn't rendered, and vice versa.

    Aside from that, I think I favor this method to any previous scheme 
using <input type="date|datetime|time">. It solves all the hard problems 
  without introducing any new problems of significance. Let me know what 
you think.