Max year in date examples is 2016

[36degrees]

The year inputs in the date examples have a max attribute of 2016.

They were last updated in #175.

How would you expect it to work?

We could:

• Update the max attribute to a year far in the future (3000? 9999?)
• Remove the max attribute entirely

[joelanman]

My vote is to remove min and max. In general I don't think we should try and introduce validation into our coded patterns. For that to be done properly it needs to incorporate server side code. It also needs error massages relevant to the context, which we don't necessarily know.

On top of that, the min/max experience in the browser is odd. I can enter 2020 in the above example in desktop chrome and safari on MacOS, and it seems to accept it. If I then use keyboard up/down (not a feature I would expect most people to know about) it snaps to 2016.

[selfthinker]

I would also remove it entirely. You also have to think about the developers who would use the date example for any date and not just date of birth, so they might end up having it in a year field which needs to be in the future.

[36degrees]

Conversely, I wonder if it would be helpful to add maxlength to the fields (2 for day and month, 4 for year). At the minute, you can type as many digits as you want into each box:

[joelanman]

That seems safer, however it's still validation with no feedback, which worries me. Say someone misunderstood and started typing 'Jan' in the month, they'd type 'Ja' and then it would just 'stop working'. I think proper validation with messaging is always preferable

[edwardhorsford]

I suggest removing this limit. I think if a service does want to put min and max digits that's something they'll need to think about - it's safer for us to not include it in the examples (and we don't have to keep it up to date either).