4 ms·

> The form cannot be submitted until the user fixes the error, so the server shouldn’t receive an excessively long text or password (a server-side validation ha

> The form cannot be submitted until the user fixes the error, so the server shouldn’t receive an excessively long text or password (a server-side validation has to be put in place anyway.) However, this could potentially affect a front-end implementation if it expects the entered text never to exceed maxlength. What century are Mozilla living in? Most, even simple forms, don't use <form> elements and submit buttons anymore, they're all aJax. Therefore this workaround will be commonly bypassed. People can debate if this is a good or bad thing, but ultimately the problem remains: This change will cause unexpected behavior when maxlength-ed stuff no longer obeys on thousands of popular websites. Even if sites check it server-side, that doesn't mean the user experience isn't substantially degraded relative to obeying HTML standards. Their justification for this change is nonsensical too: > This change mainly aims at preventing an unexpectedly truncated password from being saved. So why not limit it to input type=password? Heck why include textareas in this change, who is using a textarea for a password box?!

nerdbaggy 6y ago
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
- Someone1234 6y ago
  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.
  - renewiltord 6y ago
    Am I missing something? This seems less surprising than the alternative.
    - jeroenhd 6y ago
      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.
      - Someone1234 6y ago
        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.
        edoceo 6y ago
        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.
  - nerdbaggy 6y ago
    Interesting, I really hate it when I press enter and it doesn’t submit the form.
JakeWesorick 6y ago
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-developers-4cn0 https://dev.to/addyosmani/accessibility-tips-for-web-develop...
- Someone1234 6y ago
  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.
  - tambre 6y ago
    >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 [...]
obeattie 6y ago
You just typed your comment into a <form>
- Someone1234 6y ago
  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.
  - zeroimpl 6y ago
    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.
jeroenhd 6y ago
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.
- gruez 6y ago
  >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).
  - jeroenhd 6y ago
    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.
    - unilynx 6y ago
      You can do a lot with setCustomValidity to improve error messages while still using the rest of the HTML5 validation API.
      - jeroenhd 6y ago
lonelappde 6y ago
https://html.spec.whatwg.org/multipage/forms.html#client-side-form-validation https://html.spec.whatwg.org/multipage/forms.html#client-sid...
- Someone1234 6y ago
  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?
cmeacham98 6y ago
> 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?

nerdbaggy 6y ago

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

Someone1234 6y ago
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.
- renewiltord 6y ago
  Am I missing something? This seems less surprising than the alternative.
  - jeroenhd 6y ago
    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.
    - Someone1234 6y ago
      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.
      - edoceo 6y ago
        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.
- nerdbaggy 6y ago
  Interesting, I really hate it when I press enter and it doesn’t submit the form.

JakeWesorick 6y ago

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-developers-4cn0 https://dev.to/addyosmani/accessibility-tips-for-web-develop...

Someone1234 6y ago
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.
- tambre 6y ago
  >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 [...]

obeattie 6y ago

You just typed your comment into a <form>

Someone1234 6y ago
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.
- zeroimpl 6y ago
  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.

jeroenhd 6y ago

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.

gruez 6y ago
>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).
- jeroenhd 6y ago
  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.
  - unilynx 6y ago
    You can do a lot with setCustomValidity to improve error messages while still using the rest of the HTML5 validation API.
    - jeroenhd 6y ago

lonelappde 6y ago

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

Someone1234 6y ago
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?

cmeacham98 6y ago

> 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?