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

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

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 13 Jul 2004 14:27:33 +0000 (UTC)
Message-ID: <Pine.LNX.4.58.0407131421500.2103@dhalsim.dreamhost.com>
On Fri, 9 Jul 2004, Jim Ley wrote:
> NO! I'm not against a datetime input type, I'm against an input datetime
> time that does not provide the author with the ability to suggest the
> type of entry widget that is most appropriate for their users task.

Could you explain what you are requesting in more depth? I'm not sure I
understand what your requirement is here.

> processing random dates is expensive, especially if you're not just
> going to reject everything not in a certain format

It really isn't. It's just a bunch of pretty simple regexps and some
simple maths. Nothing compared to, e.g., the SQL query or file access that
is likely to follow.

>> It's the same problem as with phone numbers, social security numbers
>> and other formatted numerical date, and it has the same solution: post
>> an example format. Example: MM/DD/YYYY.
> Could you show me an example WF2 page using datetime that degrades to
> that please?  Since the example format solution makes no sense if the
> datetime element is rendered by a WF-2 user agent.

Two examples have been given: using value="", when there is no default
value (the common case), and using JavaScript to conditionally include
hints when running on a legacy UA. In non-JS cases with default values,
the value is likely to give enough of a hint to the user anyway.

If those aren't enough, we could look into a new element that hides
content on legacy UAs but not WF2 UAs, but (for reasons I've explained
many times) I really don't think that's a good idea.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 13 July 2004 07:27:33 UTC

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