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

[Matthew Raymond]

Jim Ley wrote:
> On Thu, 08 Jul 2004 08:00:04 -0400, Matthew Raymond
> <mattraymond at earthlink.net> wrote:
> 
>>   It improves it in two ways. First, it allows the UA to present a
>>standard control regardless of what web server is serving it up. This
>>prevents the user from being confused about how a specific site's date
>>picker works.
> 
> 
> Could you point me to some studies that show users are confused about
> picking dates on websites now?

    Rather than simply dismissing this question, I decided to actually 
spend a little time searching the Internet for a study on date pickers.
I couldn't find a study that says anything about it either way. Then 
again, perhaps Google isn't the ideal tool for finding such information...

> I've never heard it's a particular
> problem. I find the default windows date picker incredibly well
> designed for certain things, I find it just about useless for others
> taking a huge number of clicks to get anywhere

    You are describing a UI problem with a specific date picker. UAs are 
free to use their own custom date picker implementations. It seems like 
this is really only a problem if UA developers make poor design choices.

 > booking flights is
> just one of those scenarios where it's a nightmare.  Different date
> picking UI's apply to different date picking needs - if I know an
> exact date it's very different to if I need to browse through dates to
> see which is a saturday for example.

    Who's to say a date picker can't be made that allows you to both 
easily enter a date manually and easily select it through a UI. Are we 
going to deny the use of a canned control because we don't think browser 
developers can build a better date picker?

 > I think many authors of
> websites know the context that the date picker will be used, there
> isn't a good single generic date picker that works for all uses.

    It doesn't have to work well for ALL uses. It has to work well for 
MOST uses. For certain specific cases, specific solutions will always be 
better.

>>Second, it allows the user to choose a theme or UA that
>>suits them best. 
> 
> So these date pickers will not be stylable / suggestable by designers?
>  (what about in future specifications?)

    You can always use CSS or the |pattern| attribute, and for the most 
common use cases, that's really all anyone should need. Having a date 
picker does not mean giving up custom widgets for special circumstances.

>>   This also benefits the web server. By using a standard control, the
>>servers no longer have to worry about serving up additional markup and
>>Javascript for the date picker, which reduces load.
> 
> A tiny fractional load improvement, and is offset by having  the extra
> load of having to process the dates in more complicated ways from
> legacy clients, in fact from non-legacy ones too potentially.

    The cost of legacy clients is related to the cost of the legacy 
markup you use. How can that markup be greater when using WF2, where a 
single control returns a single UTC date to the server, and that control 
degrades into another single control?

    Also remember that for companies already using a text box for date 
input, the WF2 date type has virtually no development cost.

> (parsing a free form text element is a lot more complicated than
> parsing 2 select boxes such as Open Skies do.

    It is my understanding that for security reasons you have to 
validate  the input anyway, regardless of the source control. In fact, I 
recall reading a message on this mailing list a short time ago about a 
value sent to a server from a <select> element could be altered prior to 
reaching the server.

    As for two <select> boxes being more appropriate for a specific 
application, that's up to the web author. For instance, a web author may 
chose a <select>, <input type="number"> or <input type="range"> to get 
numerical input in different situations.

>>It also allows the
>>websites of smaller businesses who can't afford large web development
>>budgets to provide a more professional and robust date picker rather
>>than a text box or similar setup.
> 
> Except all they're getting on legacy clients is a textbox (unless they
> can afford the shim solution, which is almost certainly more
> expensive)

    Javascript functions for determining if a string is a date are 
available for free on the Internet. Here's one of many I found doing a 
simple search on Google:

// This is by some guy by the handle "mikr0s". I'm not suggesting this
// is the best solution, BTW. I'm just making a point.

function myIsDate(mystring)
{//--BOF
var mystring, myresult ;
var mystring = new Date(mystring);
isNaN(mystring)? myresult=false : myresult=true ;
return myresult ;
//--EOF
}

    Keep in mind, a simple validation of a text box is not the same as 
creating a full-blown date picker using DHTML and Javascript. However, 
if WF2-compliant UAs give you a date picker for free just by using 
type="date", and you still have a fallback date entry method that works 
in legacy UAs, that's pretty easy to cost justify.

 > Most dates are 2 or 3 select elements currently, anyone
> can do that and it's well understood, these smaller businesses are not
> currently losing out, so I fail to see this motivation.

    The situation you describe does not allow ranged input. (For 
instance, how do you handle February 29th on a non-leap year? What if I 
try to enter February 31st, for that matter?) In order to do ranged 
input with this setup, you need scripting to validate the entered date 
with respect to valid input ranges. If you're going to do that, you 
might as well just validate the date from a text box.

    I recently used a form that uses both a text entry for dates and a 
Javascript date picker that inputs the date into the text field for you. 
A canned date picker control would replace that solution directly.

    It should also be noted that people who use the keyboard as their 
primary method of input will probably be able to input a date into a 
text box faster than they could select one using three <select> 
elements. I'm not saying a date picker that degrades into a text box is 
ideal for all situations, but it is not an uncommon way to input a date 
on the Internet, and control of how the user enters the data is a poor 
excuse for excluding a date picker from WF2.

> Not that I don't see the ability to say I'm expecting a date here is a
> bad thing, I just don't particularly see that that is associated with
> a particular rendering is a good thing, nor is the case proven that
> there are use cases for it on the web.

    What rendering are you referring to? The UA chooses how the date 
picker is rendered. If the web author wants a custom style for the date 
picker that goes beyond what |pattern| or CSS can provide, they can use 
conventional methods or wait for Web Controls 2.0.