- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Fri, 09 Jul 2004 07:14:19 -0400
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.
Received on Friday, 9 July 2004 04:14:19 UTC