[whatwg] input element types
jim.ley at gmail.com
Wed Jun 16 09:52:05 PDT 2004
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
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.
> 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
> Yeah. I've dropped "tel" for now.
Good, 1 down, how many more features do I have left?
More information about the whatwg