- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 24 Aug 2010 15:39:11 +0300
On Aug 24, 2010, at 15:32, Andrew Hayward wrote: >>>>> * it has the *semantic* of being a year, which is a special type of >>>>> number (potentially more than four digits if you subscribe to "Long >>>>> Now"[1] methodology, or fewer than four as Andy noted). >>>> >>>> Why is it useful to declare this semantic to the browser? What functional difference do you envision compared to a field that accepts an integer (potentially with min and max values relevant to the site)? >>> >>> Future browser could offer a calendar tool to fill input fields that have a date semantic. While this would be appropriate, it would not be appropriate to offer a calendar tool for other integer data e.g. an input field that asks the user for his monthly income in USD. >> >> What kind of calendar tool is more efficient for entering a year (year only without a month or day) than a UI that is optimized for entering an integer (typically text field plus spinbox arrows that also respond to arrow keys and input method defaulting to digits on phones and similar)? >> >> (Also "future browser could" is a bit weak unless someone writing code for a browser indicates that he/she is actively implementing a given feature.) > > "Future browser" issues aside, it's entirely plausible that a browser > might allow me to drop events (from my calendar software, for example, > or just something else semantically a 'date' on the web) onto a > 'date'-identified input field, extracting the relevant pieces of > information and filling as appropriate. Do you have a concrete use case where you'd prefer to drop events to a *year-precision* field over entering a number in a field? To me, the case of dropping events seems more plausible in the case of day-precision fields. -- Henri Sivonen hsivonen at iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 24 August 2010 05:39:11 UTC