[whatwg] input element types
jim at jibbering.com
Sat Jun 12 16:58:27 PDT 2004
On the new input element types
With dates and times why the restriction on UTC? 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.
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?
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?
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. 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? Will there be any methods for a form requesting values
not directly representable in your required submission format (such as 1/3)?
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.
More information about the whatwg