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 hsivo...@iki.fi http://hsivonen.iki.fi/
