| Volker_E | |
| Oct 22 2016, 9:26 PM |
| F4644731: pasted_file | |
| Oct 22 2016, 10:00 PM |
With https://gerrit.wikimedia.org/r/#/c/317005/ we're supporting type=month in TextInputWidget, but not type=week.
For consistency let's add type=week as week and year input type as well…
DateInputWidget could support a "week" precision to provide a prettier, consistent, and more widely-available week picker that infuses over a type=week TextInputWidget.
For reference, what Chrome/Blink's week picker looks like:
A feature for DateInputWidget?
I was remembering that it was told to me before by other OOjs UI developers, that other type attributes are just added on clear use cases as several input types new to HTML5 have not been seen wide adoption.
From a code perspective it seems inconsistent, but given the arguments above, I'd rather close it as invalid now.
Please pick it up if you see a strong need.
Oh, I wasn't arguing against the task. Since I got date and month types added to TextInputWidget so that I could use them as the non-JS versions of DateInputWidgets, I was stating that if the week type was added, the corresponding week selection feature should be added to DateInputWidget to provide a nicer, more widely-available week selector.
When writing (my version of) DateInputWidget, I didn't add 'week' precision because the implementation was daunting. The way you calculate weeks depends on the language and the country in very annoying ways (weeks can start on Saturday, Sunday or Monday; and weeks that straddle year boundary are sometimes counted as part of the previous, and sometimes next year). And I couldn't think of a use case.
For TextInputWidget, I'm not really sure if we should be allowing any types that are not pure text… DateInputWidget could override getInputElement() to use the different types. But we've allowed 'day' before, so I merged the patch for 'month' as well, and thought we might reconsider that in a couple months/years… but if you want to do it now… ;)