Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
* 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.
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
* 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.
Re: [whatwg] Please consider making summary more generic/flexible (or renaming)
Summary: the new summary element is very generic sounding but has a very special purpose (only allowed inside details). It would be helpful if we made it more generic, in particular allow use of summary inside article body (and perhaps section) to provide general summary text semantics (e.g. this paragraph :), and a potential enhancement to the HTML5-to-Atom conversion algorithm. Alternatively, we could rename summary inside details to something more specific so it won't be confused as a generic-sounding element/feature. In a somewhat related note, following a real-world conversation I had with Jeremy Keith a short while ago, is there a reason why summary (or the theoretical renamed less generic alternative) isn't being used inside figures too, instead of another new element (figcaption)? At the time Jeremy wasn't able to give me an answer, but if it's already been discussed and I just missed it, my apologies. - Andrew
