W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2005

[whatwg] [WF2] The <format> Element II: The Wrath of <date>

From: Matthew Raymond <mattraymond@earthlink.net>
Date: Tue, 25 Jan 2005 09:38:24 -0500
Message-ID: <41F659E0.1040709@earthlink.net>
    One of my concerns with the <format> element as previously defined 
is that if the users sees a localized version of the date and time in 
their <input type="datetime"> controls, it may not match text dates and 
times elsewhere on the page or website. As a result, there are only 
three possible solutions:

1) Force the date/time control to display the format of the <format> 
element (applyon="entry").

2) Preconfigure the settings of the user agents to display a specific 
format in all date/time controls.

3) Require WF2 user agents to display dates and times in the text in a 
localized format.

    I believe the third option is the most logical and provides the most 
comprehensive solution. Using <date>/<time>/<datetime> bypasses the need 
for any configuration of specific user agents, and it allows users more 
choice and greater consistency with regards to their user interface. It 
also has a number of advantages outside of simple localization, since 
the user agent could use the date/time to schedule an event in a 
calendar program or something similar.

    So here's how it would work in the markup...

Simple example:

| <p>
|   The meeting is currently being held on <date>2005-1-30</date>
|   at <time>11:00:00.0</time>.
| </p>
|
| <form>
| <label>New Meeting Date:
| <input type="date" value="2005-01-30">
| <format>Format: yyyy-mm-dd</format></label>
|
| <label>New Meeting Time:
| <input type="time" value="11:00:00.0Z">
| <format>Format: hh:mm</format></label>
| </form>

    Because the contents of <date> and <time> are already in ISO8601 
format, no |value| attributes have to be specified. The format to submit 
is ISO8601 as well, so format doesn't require a |value| attribute.

Complex  example:

| <p>
|   The meeting is currently being held on
|   <date value="2005-01-30">January 30, 2005</date>
|   at <time value="11:00:00.0Z">11:00 PM</time>.
| </p>
|
| <form>
| <label for="meetdate">New Meeting Date: </label>
| <input type="date" id="meetdate" name="meetdate" value="2005-1-30">
| <format for="meetdate" min="2005-01-25" max="2006-01-30"
| value="%m/%d/%Y">
|   Format: mm/dd/yyyy
| </format>
|
| <label for="meettime">New Meeting Time: </label>
| <input type="time" id="meettime" name="meettime" value="11:00">
| <format for="meettime" value="%I:%M %p">Format: hh:mm am/pm</format>
| </form>

    In the above example, all |value| attributes are specified. Note 
that the fallback values for <date> and <time> are no longer in ISO8601 
format. Also, the submission formats have been changed, so we have to 
add |value| attributes to the <format> elements, which in the above 
example contain format strings that use subsets of the formatting for 
strftime:

[1]http://us2.php.net/strftime
[2]http://developer.apple.com/documentation/Cocoa/Conceptual/DataFormatting/Concepts/DateFormatters.html

    We may need to make minor modifications or additions to the strftime 
formatting to allow for a little more flexibility with regards to how 
dates are displayed.

    Note that the default submission format for <format> is ISO8601, and 
that if another format is specified, that date will always be used for 
submission, yet the user agent determines the presentation to the user, 
which would presumable be in their native format or one of their choosing.

    If you were targeting WF2-only user agents, then you could just do 
something like <date value="2005-01-30"/>. However, you've just killed 
any kind of fallback scenario if you do, and it's easier to just do 
<date>2005-01-30</date>. If there is no |value| defined, and the user 
agent can't parse the child contents, the user agent should probably 
just render the child contents in the same way as a legacy user agent.

    Also note that I'm changing my definition of <format> so that the 
child contents are purely a fallback for legacy clients. Why? Well look 
at this example:

| <label for="date1">Departing:<br></label>
| <input id="date1" name="date1" value="mm/dd/yy">
| <format for="date1" min="now" value="%m/%d/%Y">
| <input src="/eta/calendar.gif" name="cbtn1" alt="View Calendar"
| type="image">
| </format>

    The above is a modified version of the markup Expedia.com uses for 
date entry for Mozilla Firefox in the "flights" tab. Because <input 
name="cbtn1"> is unnecessary on a WF2 user agent, the element has been 
made a child of <format> so that it will not be rendered. A similar 
solution, with the help of some Javascript, could probably be used to 
create three <select> elements in fallback rather than an <input 
type="text">. I'm working on an idea for how to make this possible 
without Javascript. Feel free to post comments.

    For people who want specific date formats displayed, perhaps we need 
special CSS properties for this purpose. Perhaps something like this:

    date, input[type=date] { format-date: "%m/%d/%Y" }

    ...However, I think that falls outside the scope of WHATWG. The use 
case seems rather week to me as well, which is pretty much "the 
webmaster wants WF2 UAs to render dates in this format".

    I believe this addresses nearly all outstanding issues regarding the 
<input type="date/time/datetime"> elements. At the very least it covers 
all the problems I know of concerning scenarios with a <input 
type="text">-based fallback. Please let me know if there are additional 
concerns that have not been addressed.
Received on Tuesday, 25 January 2005 06:38:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:21 UTC