Hacker News Reader

A lot of people still put them in forms. They just intercept the form submit to do with as the please. No putting them in a form also breaks accessibility

And a lot of sites don't. "This breaks a ton of things but not everything" isn't a good attitude to browser compatibility, particularly from a browser that already has a small market share.

> No putting them in a form also breaks accessibility

Nope. Screen readers have no concept of <form> fields, nor any concept of how the piping works below the surface when a <button> is pressed. I run a screen reader every single day.

Am I missing something? This seems less surprising than the alternative.

One breaks the expectations of users, the other breaks the expectations of developers. On a website full of developers you'll probably see a lot more from one side than from the other.

I'm pretty sure being able to input text longer than the maximum allowable text into a field breaks user's expectations too. Users don't "win" because you made how a site works more confusing.

Their justification for this change is the only user-win (password truncation), and they could have trivially restricted this to passwords then body is hurt.

Users don't expect the length limit! that info isnt presented to them until the text is over-long and the clue is: Surprise! Truncate w/o warning. On more than just password fields.

Interesting, I really hate it when I press enter and it doesn’t submit the form.

Even if you use AJAX forms for logging in or registering (I'd prefer you didn't but whatever), you should still use the proper form validation API for things like this. If you use the proper HTML API for gathering data properly, you're most likely not affected badly functionality wise; only your UI will be affected because the form will refuse to be posted without proper explanation.

If the change really does get bypassed by everyone, that only underlines the sad state of modern website design relying completely on javascript.

I'm not sure why they don't limit this to just passwords but I can imagine it's easier to change the behaviour for all form elements than it is to change the behaviour of just password fields.

>Even if you use AJAX forms for logging in or registering (I'd prefer you didn't but whatever), you should still use the proper form validation API for things like this.

You don't even need to use "the proper form validation API". It's as simple as changing your ajax call from an onclick (on the submit button) to an onsubmit (on the form).

Agreed. Though, as a developer, I like to extend the submission actions a little bit to make error messages fit in with the rest of the site and maybe suggest what to do in order to correct the input (e.g. remove letters from phone numbers, pick a better password, etc.)

I do consider using the HTML5 form validation to be the proper validation API. Browser can do a lot without javascript and relying on their default behaviour is still making use of the validation API.

You can do a lot with setCustomValidity to improve error messages while still using the rest of the HTML5 validation API.

You're totally right, but the Firefox popover indicating what's going wrong doesn't go with some of the designs I make. On a bootstrap-based design I much prefer bootstrap-style error messages which are easy to do with Javascript, and the same is true for Material-based designs.

I do think that people generally overlook the built-in form validation though, and I like to use them as a fallback for Javascriptless environments to ensure everyone can get proper validation.

It's important to use form elements for accessibility even if your submitting another way. Also at least for me its a lot better to use the built in form validation then creating your own.

https://dev.to/addyosmani/accessibility-tips-for-web-develop...

Your link doesn't support your statement, or even attempt to. Screen readers have no concept of <form> elements, nor do they differentiate on what happens behind the curtain when a button is pressed (e.g. aJax Vs. submit).

If you have an article that does explain your argument, please link it.

> Also at least for me its a lot better to use the built in form validation then creating your own.

This change removes that very validation.

>This change removes that very validation.

How? The form can't be submitted until it's fixed.

>The form cannot be submitted until the user fixes the error [...]. The user will typically see a red border around the text field along with a validation message [...]

You just typed your comment into a <form>

So Mozilla's non-standard compliant change broke one fewer site, problem solved?

Even for this site, why is Mozilla not limiting this breaking change designed to fix password fields to: Password fields. They haven't described why type=text or even textarea should be non-standard, only why type=password should be.

If they limited this to password fields, I'd have no issue. But per the code change they did not.

I’ve had issues pasting phone numbers into text fields, where the last digits get cut off because the form doesn’t want hyphens. I’d rather it paste in the full thing and then let me manually remove the hyphens/spaces.

> Most, even simple forms, don't use <form> elements and submit buttons anymore, they're all aJax.

> This change will cause unexpected behavior when maxlength-ed stuff no longer obeys on thousands of popular websites.

Does nobody or "thousands of popular websites" use <form>? Which one is it?

https://html.spec.whatwg.org/multipage/forms.html#client-sid...

Your link says to use the very attribute that Mozilla are breaking in this change. Can you explain whatever point you're trying to make?