[whatwg] input element types

[Jim Ley]

On Wed, 16 Jun 2004 16:29:13 +0000 (UTC), Ian Hickson <ian at hixie.ch> wrote:
> 
> On Sun, 13 Jun 2004, Jim Ley wrote:
> >
> > With dates and times why the restriction on UTC?
> 
> Only with the "datetime" type is there that restriction; it is intended
> specifically to cater for the situations where a time-zone-defined time is
> needed.

Right, so not much use at all really then, seen as we generally have
timezone dependant dates for almost all internet use.  I want to know
when my train arrives in London if I leave today.  Seen as we can't
have the legacy clients deal with the timezone issues, and we add a
dependance on the client knowing the UTC offset of the user I think
it's all rather over-specified and un-implementable.

[flight example]
> Indeed. For this use, the "time" type is available.

So we cannot use the datetime control for travel sites?  Rather
inconvenient is it not?

> Truncated representations don't seem like they would require much in the
> parser. You just set anything you haven't read yet to zero.

You seem to be mis-remembering ISO 8601, the truncated representations
don't default to 0.  Maybe a quick refresher course, perhaps you could
assign an Action to one of the other working group, they don't seem to
be doing much work on the spec.

> > week: one of the more popular uses of weeks in the UK is the tax week,
> > this of course doesn't work as an ISO8601 week, could the week widget be
> > generalised so it can be used for these other definitions of week?
> 
> Possibly; how would you do it? (I don't know enough about the UK Tax week
> to know exactly what needs generalising.)

The date that is week 1.

> > Why are +0 etc. invalid?  The MUST restriction on the UA to not submit
> > numbers in invalid formats is required why, surely SHOULD is more
> > appropriate?
> 
> It has to be "MUST" so that servers are guarenteed to always be able to
> parse the result. Why would it be "SHOULD"?

Because of the over-validation suggestions I've talked about before on
the list, servers cannot rely on the format being returned, since
servers cannot rely on a Web Forms 2.0 client.

> > Will there be any methods for a form requesting values not directly
> > representable in your required submission format (such as 1/3)?
>
> Not in this version, but what did you have in mind?

A method for requesting numbers not representable in your format... 
as to how it might look, I have no idea yet, I've not really thought
about it.

> Yeah. I've dropped "tel" for now.

Good, 1 down, how many more features do I have left?

Jim.