- From: Jim Ley <jim@jibbering.com>
- Date: Sun, 13 Jun 2004 00:58:27 +0100
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. Jim.
Received on Saturday, 12 June 2004 16:58:27 UTC