- From: Jim Ley <jim.ley@gmail.com>
- Date: Tue, 13 Jul 2004 15:45:48 +0100
On Tue, 13 Jul 2004 14:27:33 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote: > 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. That a datetime control degrades into something usable, I've explained it lots of time in this thread. > It really isn't. It's just a bunch of pretty simple regexps and some > simple maths. 04/07/2004 4th July 04 7/4/04 2004-7-4 4/7/4 1.091574000e+12 Massaging all of those (well perhaps not the last) into the date intended by the user, is not simple, it's a lot more complicated than, just taking the date/month/year from the 3 input controls on most international forms today. > > 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), No, it's not - that may be the common case for when you first enter a form, but even those forms upon an invalid response in it will repopulate the form with the invalid data. This makes the approach unworkable for me, as after a validation failure I cannot leave the user value in there. Quite apart from it failing in all the other cases where authors wish to set up a value. > In non-JS cases with default values, the value is likely to give > enough of a hint to the user anyway. You've still not explained how javascript can identify a datetime supporting UA, and until you do this, you cannot advocate a javascript solution! > If those aren't enough, we could look into a new element that hides > content on legacy UAs but not WF2 UAs, Why bother, when we already have an HTML 4 compatible way of achieving this (OBJECT) which is only being rejected not because it doesn't degrade on IE, but because it does! That really seems a ridiculous reason to me. > but (for reasons I've explained > many times) I really don't think that's a good idea. No, it's a poor one, but there are more options to solving the problem, which don't seem to be been given sensible consideration. Jim.
Received on Tuesday, 13 July 2004 07:45:48 UTC