[whatwg] Suggested changes to Web Forms 2.0, 2004-07-01 working
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.
4th July 04
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.
> 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.
More information about the whatwg