[whatwg] Suggested changes to Web Forms 2.0, 2004-07-01 working
ian at hixie.ch
Tue Aug 17 07:36:49 PDT 2004
On Wed, 14 Jul 2004, Jim Ley wrote:
> On Wed, 14 Jul 2004 10:02:08 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 13 Jul 2004, Jim Ley wrote:
> > > 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.
> Could you list these enhanced proposed syntaxes again?
No, you are just as capable of reading the archives as I am.
> > >> 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.
> Point me to a library then... any language...
See the "parseDateTime" function at the bottom of:
> > > 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.
> You appear to be confusing my point - common here, I'm obviously very
> poor at getting them across.
> Upon submission of a form, that results in a validation error, or other
> reason to return to the page (perhaps a "choose a new destination on a
> flight map") develepors populate the form with the previous entry - this
> is the initial value problem, it does not mean that on first entry pages
> necessarily have a default value.
If you have received an invalid value, you know it is a non-WF2 UA. You
can thus write whatever markup you want to handle the non-WF2 UA.
> > Yes, I have. Just check if "input.type" is equal to "datetime" (or
> > whatever type you are checking for).
> I've already demonstrated UA's that do not do this the last time you
> suggested it as the solution. Please try again...
I just tested this again, and all the UAs I tested, did this fine:
Since this is required behaviour by the specs, that's good enough for me.
> > > 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.
> I understood the requirement to be degradeable in downlevel browsers
> including the ability to provide more enhanced fallback of the new
> features, via both browser plugins and scripting in UA's such as
> Internet explorer.
> What I did not understand it to mean, is that the implementation of
> the features in IE (what does that mean by the way, which versions
> platforms etc. Could you clarify the design goals, if they're not
> what my first paragraph gives) were dependant on a particular
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg