- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 13 Jul 2004 14:27:33 +0000 (UTC)
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