[whatwg] input element types

[Ian Hickson]

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.

> There are many cases where you want to enter times relative purely to
> local time - for example booking a flight to arrive in Madrid by 9am, to
> require the user agent to not only know the timezone of the user agent
> correctly, the local summertime changes, and the timezone of Madrid to
> usefully perform the conversion to UTC seems unusually complicated, and
> well beyond what is currently realistic in IE6.

Indeed. For this use, the "time" type is available.


> You regularly say "encoded according to ISO8601" - I assume you actually
> mean some subset of the available options since I do not imagine you
> indend the added complexity of allowing the truncated representations?

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

(I would like to drop the dependence on ISO8601 and just define the
formats in the spec directly, but have not yet gotten around to it. I'm
not sure if I will, it probably depends on the results of the test suite
when we start writing tests for this.)


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


> number: What happens when the device is incapable of providing numbers
> within the required precision - should it error, truncate the value
> without informing the user.

Added a paragraph about this in the new step="" section.


> 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"?

Plus signs are disallowed to make the server-side parsing easier (not by
much but every little helps).


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


> tel: This strikes me as very difficult to implement, very few people
> tend to enter a global-phone-number, which means you're going to need
> your UA to convert between local and global number for the required
> submission (or alternively reject it until the user gives up in
> frustration.) I can't see how it can do this safely.

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

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