- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 25 Jun 2004 21:19:53 +0000 (UTC)
On Fri, 25 Jun 2004, Will Levine wrote: > > Right now, my mind is stuck and I can't think of any uses for a number > input outside of an order form (which would require integers the > majority of the time), but I am sure that there must be many forms that > wouldn't want only integers. Constraining input by default doesn't seem > like the right solution. There has to be a default step. Why would one pick a default that wasn't the most common choice? > For date and datetime, you can submit years with more than four digits. > Why don't we constrain the years in dates by default? I think planning > 8000 years in advance is less common then allowing non-integer input. > Dates far in the future (or in the past) would probably frustrate most > scheduling programs like fractional numbers would screw up the ordering > program. That is the "max" attribute. I suppose we could default "max" to some date in the future, but it doesn't seem like there is a single date that is particularly common as the maximum. > Is there any time one would need to be precise to the second in a Web > app or are you just including the stuff about seconds and fractions of > seconds because you want to use an existing standard? Will using this > standard make it easier for server-side scripts to parse the date/time? > If we do need to use this existing standard, could we just ignore > seconds and tell the UA to only ever ask for time precise to the minute > and just submit that time with 00.0 seconds? This would seem ideal to > me. I can think of a few cases where time in seconds would be important, > but nothing that one would put in a Web app. Sub-second accuracy is useful in scientific applications. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 25 June 2004 14:19:53 UTC