[whatwg] Please consider adding a couple more datetime <input> types - type="year" and type="month-day"

[Andrew Hayward]

>>>>>> * 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.