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

Jim Ley jim.ley at gmail.com
Tue Jul 13 07:45:48 PDT 2004


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.



More information about the whatwg mailing list