[unlog]

In an all honest reply, is that the people that writes these specifications, live disconnected from the reality, they don't use the stuff they specify. That stuff works for very simple things, but then when your forms evolve you realise you will be better off just writing the whole thing yourself.

[marcus_holmes]

This. Doing relatively common things like cross-referencing from other fields ("did the user specify a country? If so, we can validate the postcode/zip code they just entered, but if not we'll have to wait until they pick a country") almost immediately require JS to handle, and as soon as you're using JS then it's all just easier to do in code than trying to mess around with validation properties.

[jhardy54]

Yep. This is great until you need a cross-browser date picker, at which point you need to implement a bunch of stuff yourself. It’s frustrating how primitive HTML forms are, after so many years.

[kmoser]

What do you mean? Most browsers support <input type="date"> natively just fine.

[lelanthran]

> What do you mean? Most browsers support <input type="date"> natively just fine.

The `<input type=datetime-local>` on FF has a broken time-picker[1], has always been broken, and there are no plans to ever fix it, ever.

[1] In that it will let you pick a date, but not a time - the time must be manually typed into the input!

[francislavoie]

What's hilarious is they do have UI for it in about:config "dom.forms.datetime.timepicker". It makes me so angry that it's not on by default. It works fine!

[cuu508]

On Android, the date picker widget is fiddly to use for selecting distant dates, like date of birth. Not impossible but requires many many taps.

[sureIy]

That's an implementation issue, not a specification issue. The specification just suggests the user is shown a date picker.

[talkin]

You’re technically right but that doesn’t matter.

That you’re correctly using html forms won’t quickly lead to browser improvements.. so the result is that users will hate your forms. Users/your customer might possibly even think that you’re to blame, and not $browserVendor.

[BalinKing]

I’ll go one further and say that the customers are absolutely justified to blame the developer instead of the browser. If a developer knowingly chooses a built-in form control whose common implementations are bad for their users, how are they not at fault for the resulting experience?

“This site only uses functionality provided by the HTML spec” is not a useful goal in and of itself. Using the right tool for the job, which might be JavaScript, is always more important.

[alexvitkov]

It doesn't really matter whose fault it is, the end result is that your users have bad experience on your website.

[jeroenhd]

I've never had a problem with that myself. I guess people don't know you cab tap the year in the date picker to quickly go back a bunch of years?

[nitwit005]

Most of the forms features are from the early 90s. You're not working in the same millennium as some of the specification writers.

[skrebbel]

The `required` attribute, which this article is about, is an HTML5 thing and first appeared in browsers in 2010-2011. So sure, not brand spanking new, but the web was already used to write modern apps. There's no good reason for the validation features to be so shabby.

[Sander_Marechal]

Even 'required' doesn't work properly. Browsers do very odd and inconsistent things when your required field is hidden when submitting. Like in a basic tabbed or multi-step form.