[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.
Wait...
http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/001308.html
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-whatwg.org
mailing list