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

[Ian Hickson]

On Tue, 13 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.

Oh, you're still only requesting that. Ok. I think we have explained lots
of times in this thread why we think that's already available, and better
than the few other proposed syntaxes that I've seen which would have more
complete possibilities for fallback.

If you have a more specific request it would be easier to address it than
such a general request.


>> 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.

It's not trivial, sure. But it's still pretty simple.


> > > 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.

I maintain that it _is_ the common case. In the 50 or so pages with forms
that I looked at yesterday, only about 2 had an initial value. That's 96%
of cases having no initial value. Indeed, several had the format as a
"fake" initial value, exactly what has been proposed for the non-JS case.


> > 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!

Yes, I have. Just check if "input.type" is equal to "datetime" (or
whatever type you are checking for).


> > 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.

The idea is to implement these features in IE. That's a requirement.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'