[whatwg] Suggested changes to Web Forms 2.0, 2004-07-01 working

[Matthew Raymond]

Jim Ley wrote:
> Chris Kaminski <chris at setmajer.com> wrote:
>>>I don't normally see many companies using a text box for date
>>>input, and I couldn't even find one in a quick search,
>>>certainly none of the airlines, or banking systems I use
>>>regularly do it.
>>
>><http://www.qjump.co.uk/>
>><http://www.nationalrail.co.uk/planmyjourney/time_table/
 >>journey_requirements.asp?&T2ID=8447_2004799509>

    Don't forget <http://www.expedia.com/>. In fact, one would think 
that situations where you know the EXACT date you want would be best 
suited to a text box.

> Great examples!  Also of course great examples of the problems with
> datetime in legacy UA's

    Actually, since they're examples of where a text box is used already 
without the influence of Web Forms 2.0 on design decisions, they are the 
sites that would benefit most directly from using <input type="date"> 
and <input type="time">. (You can use them either separately or together 
as a "datetime", which is good in situations you need either one or the 
other.)

 > they use a single text entry box, but use
> text on the page to show the format, as soon as we use <input
> type=datetime> instead of text there, things change.

    Yeah, it changes to date or time pickers they're going to see on 
hundreds of other WF2-compliant sites.

 > We can't add the
> text dd/mm/yy to the document, since that's going to be gibberish to
> someone presented a date picker where they can't use that format.

    The format presented to the user is a localized one from the OS or 
UA configuration, and the user is presented with the same date format 
every time, so this actually benefits people who go to sites from other 
regions with this kind of date input, as they no longer even have to 
worry about format.

    You seem to be arguing that instead of these sites making a minor 
change that significantly improves date selection on next generation 
clients, they should expend valuable resources changing their legacy 
date selection method. This is not rational. Keep in mind that the 
server is set up to receive a single value for the date, not three. 
Changing to your system would require an alteration of BOTH the web page 
source sent to the client and the server applet handling the submitted 
data. A WF2-compliant solution, in theory, only requires a few instances 
of the string "text" be changed to "date" or "time".

    The one problem I do see with the current WF2 system is that web 
developers may need WF2-compliant user agents to submit the date in a 
legacy format rather than ISO8601. A simple solution is to add the 
|pattern| attribute to date and time-related input types and use the 
|pattern| to determine how the date and/or time will be submitted, with 
ISO8601 being the default.

> So
> this I think shows it clearly how degrading to a textbox in a datetime
> will cause problems in understanding what dates are.

    All of the examples we provided have format hints of one kind or 
another. Two even fill in the current date for you. And keep in mind 
that confusion over date formatting is going to be greatest when people 
are using sites from another locale. They'll have memorized the one from 
their own locale.