W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2004

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

From: Jim Ley <jim.ley@gmail.com>
Date: Thu, 8 Jul 2004 13:23:31 +0100
Message-ID: <851c8d31040708052324f06977@mail.gmail.com>
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?  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 - 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.   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.

> 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?)

>    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. 
(parsing a free form text element is a lot more complicated than
parsing 2 select boxes such as Open Skies do.

> 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)   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.

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.

Jim.
Received on Thursday, 8 July 2004 05:23:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:35 UTC