>>>>>> * 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.
No, but if I were able to drop 'events' onto 'date' fields, then I'd expect all date-related fields to behave the same, regardless of how precise they were.
