whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8k stars 2.62k forks source link

Consider adding <input type="year"> #3281

Open guss77 opened 6 years ago

guss77 commented 6 years ago

Different applications need to receive time input in different resolutions, not only "just date" or "just the time part".

As the standard already defines "month" and "week" as valid resolution points for receiving time input, and as a lot of applications need a "year" input (time specification with a resolution of a year) - and are currently using horribly long and hard to navigate select lists, it makes sense to offer a "year" input type and allow browsers to implement useful UIs to select a year easily (for example, a box showing the two decades as a 4x5 greed, similar to how the current Chrome date picker UI shows months when clicking the month selector).

annevk commented 6 years ago

Heya, welcome. I recommend reading https://whatwg.org/working-mode and https://whatwg.org/faq#adding-new-features to get a feel for what it takes to add new features to a Living Standard.

This was suggested before https://lists.w3.org/Archives/Public/public-whatwg-archive/2010Aug/thread.html#msg246 and came up again later in https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Mar/thread.html#msg56.

Part of the sentiment was that you could just use <input type=number>. The counter argument seems to be that at least for the Japanese locale a different UI could be shown (and iOS might have such an implementation).

A compounding problem here is that implementers have been somewhat reluctant to add new form controls, with Firefox only recently adding support for date and time, but not yet having week, month, or datetime-local, and desktop Safari not really having any of them. We should probably wait until there's more solid adoption of the current set before adding more.

guest271314 commented 6 years ago

You can use <input type="number"> , min, max attributes to restrict range of selections and placeholder attribute to notify user that the expected input format is YYYY. At input event pass the .value or .valueAsNumber to first parameter of new Date()

<input type="number" placeholder="YYYY" min="2017" max="2100">
<script>
  document.querySelector("input[type=number]")
  .oninput = e => console.log(new Date(e.target.valueAsNumber, 0, 1))
</script>
guss77 commented 6 years ago

@annevk - I didn't go over the mailing list, for obvious reasons. I understand the concerns you raised, but I still think that in an ideal world this would be a good feature to have, so I think this ticket should stay open - at least so that in three years when that issue will be raised again - it'll be easier to this discussion in Github.

Also @guest271314 - I think that type=number is a horrible alternative: the spinner controls implemented by browsers are almost for spinning through a range that could be as large as 50 years or more - a <select> is already a better solution. The only advantage of an <input type="number"> over <select> is that users can type the year in - which users are normally very loath to do. A popup like a date/week/month input would have been so much easier.

But as I've said, lets keep the discussion open until browsers will be more willing to support various date inputs.

guest271314 commented 6 years ago

@guss77 We can set the elements within ShadowDOM of <input ="date"> at blink which render "mm", "dd" and "/" to display:none using CSS, though doing so affects the .value of the element, that is .value is "" and .valueAsDate is null and neither input nor change events are dispatched

  <style>
    input::-webkit-datetime-edit-month-field,
    ::-webkit-datetime-edit-day-field,
    ::-webkit-datetime-edit-text {
      display:none;
    }
  </style>
  <input type="date">
guest271314 commented 6 years ago

Should the .valueAsDate be set to January 1 of the the selected year?

TheoryOfNekomata commented 6 years ago

Referring to the scenarios where input[type="year"] would be sound, I think years could be represented alongside with eras. For example, 1 BC would be counterintuitive to be represented as 0 for a number input, but technically 1BC is the year before 1AD. This is one such case; there could be other year representations in other calendars.

Eras could be added for ease of jumping across large spans of time as well.

saivijayan commented 5 years ago

while typing year in field it enter more than 4 digit .how to control

giocap99 commented 5 years ago

while typing year in field it enter more than 4 digit .how to control

add max="9999" in the input field.

mpazik commented 2 years ago

I find the "input type=number" a poor alternative because:

It would be amazing to see the year next to the other interval types.

masego-arnat commented 2 months ago

has this been resolved because i field myself having wanting to use but it still isn't available