[whatwg] [Web Forms 2.0] Last minute suggestion - The <format> element.

Matthew Raymond mattraymond at earthlink.net
Thu Jan 20 19:50:54 PST 2005

    I've been bugged for a while by the problem of formatting hints for 
date and time inputs. The current model requires that either the server 
determines the format for itself...

| <label>Start date: <input type="date" name="start"></label>

    ...Or that the server recognize two separate formats and WF2 UA 
users just ignore the hint:

| <label>Start date (MM/DD/YYYY - WF2 browser users should ignore):
| <input type="date" name="start"></label>

    This also means that servers that used to only accept one format 
when using HTML 4.01 must now be reworked to accept at least two formats 
(unless they always used ISO8601). This is less than idea no matter 
which of the above you choose, so I would like to suggest an alternate.

    I think we should introduce to WF2 a new element called <format> 
that would contain the formatting hint text. This element would be 
rendered in legacy user agents as text, but in WF2 user agents, its 
contents would be used in a far more intelligent manner. Take this 
example, for instance:

| <label>Start Date <format>(MM/DD/YYYY)</format>:
| <input type="date" id="startdate"/></label>

    In the above, a fallback UA would render the contents of <format> as 
part of the <label> element, while a WF2 UA wouldn't be required to 
render anything, or even to use this format in the date control. This is 
because the formatting is not applied to a date and/or time control 
unless the |applyon| attribute is set to either "submit" or "entry". The 
default for |applyon| is "none".

| <label for="startdate">Start Date: </label>
| <input type="date" id="startdate"/><br/>
| <format for="startdate">MM/DD/YYYY</format>

    The above is the same example with the formatting separate from the 
<label>. Note that because <format> can't inherit the |for| attribute of 
a parent <label>, it must be specified explicitly.

    By adding the |applyon| attribute and assigning it the value 
"submit", we can require a WF2 user agent to submit the date in the 
specified format ("MM/DD/YYYY"):

| <label for="startdate">Start Date: </label>
| <input type="date" id="startdate"/><br/>
| <format applyon="submit" for="startdate">MM/DD/YYYY</format>

    Some webmasters, however, may want everyone to enter the date in the 
exact same format, for the sake of consistency (which would be useful to 
simplify employee training, for instance). This can be accomplished by 
assigning the value "entry" to the |applyon| attribute:

| <label for="startdate">Start Date: </label>
| <input type="date" id="startdate"/><br/>
| <format applyon="entry" for="startdate">MM/DD/YYYY</format>

    The above would both request the date from the user in the format 
"MM/DD/YYYY" and submit it in that format as well. (I can change this if 
someone can give me a use case regarding why you'd want them to input in 
a specific format and not submit it in that format as well. I doubt that 
will happen, though...)

    If you wanted to simply use the default WF2 formatting (ISO8601), 
you'd do this:

| <label>Start Date <format>(YYYY-MM-DD)</format>:
| <input type="date" id="startdate"/></label>

    Here's a time example:

| <label>Start Time <format>(hh:mm:ss.ss)</format>:
| <input type="time" id="starttime"/></label>

    In summary, I believe this new <format> element will allow 
appropriate data entry hints for legacy browsers without confusing WF2 
browser users, and that it will also allow webmasters to use WF2 markup 
in their forms without changing their pre-existing server-side date and 
time validation.



    Hmm. Looking back on this, this is similar to my <timeformat> 
suggestion a while back, but this version would allow UA vendors the 
option of forcing the use and submission of specific formats. Also, the 
formatting hint could be hidden entirely on WF2 user agents by making 
the default style for <format> "display: none".

    Overall, I feel that <format> is better than <timeformat> because it 
solves a wider range of problems with a minimum of additional markup.

More information about the whatwg mailing list