Fix Input Fields validation message

[Jerit3787]

Proposed changes

Fixes #437

This pull request aims to fix input fields validation. This feature were removed during the transition to vanila JS. This code has been refactored from older code which composed from jQuery.

Screenshots (if appropriate) or codepen:

Before (v2.0.3-alpha) - Preview:

After (branch textfield-fix) - Preview:

Types of changes

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to change).

Checklist:

• I have read the CONTRIBUTING document.
• My commit messages follows the conventional commit format
• My change requires a change to the documentation, and updated it accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[Lord-Leonard]

Wouldn't it be sufficient to check weather or not the text are has a "data-length" Attribute?
If it has, it indicates that the user wants the textarea to be validated.

[Jerit3787]

Yeah, that could work. I couldn't find anything referencing the validate attribute other than this part. As I stated, this is the code from previous version of it. Not sure if it could be impacting anything else so far.

Referencing here from v1.0.0:

M.validate_field = function(object) {
    let hasLength = object.attr('data-length') !== null;
    let lenAttr = parseInt(object.attr('data-length'));
    let len = object[0].value.length;

    if (len === 0 && object[0].validity.badInput === false && !object.is(':required')) {
      if (object.hasClass('validate')) {
        object.removeClass('valid');
        object.removeClass('invalid');
      }
    } else {
      if (object.hasClass('validate')) {
        // Check for character counter attributes
        if (
          (object.is(':valid') && hasLength && len <= lenAttr) ||
          (object.is(':valid') && !hasLength)
        ) {
          object.removeClass('invalid');
          object.addClass('valid');
        } else {
          object.removeClass('valid');
          object.addClass('invalid');
        }
      }
    }
  };

From the code above, this seems linked to the textbox that have character count. I might have to recheck the CSS behavior.

[Lord-Leonard]

Can't we attach the validate Function to the input field directely?

[Jerit3787]

yeah kinda, here I find kinda wierd checking for input element inside the function and outside of it. But, to be frankly speaking, the old jQuery code only checks for the length and applies the validate_field immediately.

Referencing here from v1.0.0:

$(document).on('change', input_selector, function() {
      if (this.value.length !== 0 || $(this).attr('placeholder') !== null) {
        $(this)
          .siblings('label')
          .addClass('active');
      }
      M.validate_field($(this));
    });

Since the textbox are now being handled by CSS, I think we can drop the length check. Again, I need to confirm the CSS behavior again.

[wuda-io]

Hello @Jerit3787
Thank you for your PR, here the intention that the validation function was removed:
The validation should be done on the server-side if possible. It was removed because it is not a good practice and to prevent bad security. Also to force the users to write their own custom validation function.

So as a solution maybe we could add a custom function as @Lord-Leonard stated. And the property could then be called untrustedValidationFunction.

[Jerit3787]

Hello @Jerit3787 Thank you for your PR, here the intention that the validation function was removed: The validation should be done on the server-side if possible. It was removed because it is not a good practice and to prevent bad security. Also to force the users to write their own custom validation function.

So as a solution maybe we could add a custom function as @Lord-Leonard stated. And the property could then be called untrustedValidationFunction.

If that's the case, the docs need to be updated accordingly as well. The docs contains features that are removed which I thought the feature was accidentally remove without notice. I noticed there were forms of textfield that contains error, not sure what are they for. We could add this as a notice that these needed to be handled manually.

p/s: the reason I think this is needed is because I don't use this library on server-sided processing such as node.js. Having these features manually coded ultimately defeats the whole security purpose. And this just disables the regular html textbox validation if moved to server-sided. Just my two cents.

[wuda-io]

Hey @Jerit3787
I dont wanted to be mean, your PR is still cool and good! I found a good article how we should handle this situation and how we can solve this. Check out the following article: https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation

Maybe we can get it to work without JavaScript in first place. Only via CSS pseudo class ``:invalid```
And on top of that we could add a custom callback function which checks for special properties or so.
What do you think?

[Jerit3787]

Hey @Jerit3787 I dont wanted to be mean, your PR is still cool and good! I found a good article how we should handle this situation and how we can solve this. Check out the following article: https://developer.mozilla.org/en-US/docs/Learn/Forms/Form_validation

Maybe we can get it to work without JavaScript in first place. Only via CSS pseudo class ``:invalid``` And on top of that we could add a custom callback function which checks for special properties or so. What do you think?

Yeah, sorry if my message looks like I’m mad :). Maybe we could look at it but currently I don’t really have the time to finish this yet. I’ll try work on it later.

[Jerit3787]

I've tried some examples using css instead of js. But, there is some concerns.

1. Textfield will show green if the field is empty.
   
   Thus, the data-correct will be need to be removed to avoid confusion.

[gselderslaghs]

The validation should be done on the server-side if possible. It was removed because it is not a good practice and to prevent bad security. Also to force the users to write their own custom validation function.

@wuda-io this would be bad practice from my opinion, in general the validation should be done within client-side as well as on server side, this could potentially reduce stress on the server side. Validation on client-side ensures the end-user gets notified in-moment on faulty input, it helps to ensure the server side can process the users input properly and would reduce HTTP requests. Client-side HTML5 input field validation was basically already introduced in 2013. Beside being a web standard for over a longer periode of time, it also has advantages on web accessibility: W3 - Validating common input

Excerpt from W3 - Validating Input

Custom validation needs to notify users in an accessible way as described in the User Notifications part of this tutorial. Client-side validation alone does not ensure security; therefore data needs to be validated on the server-side as well.

This seem to work properly on submit in combination with the Materialize library, the above example and example in #437, the CodePen is apparently missing the submit button. In case of form input without a submit button, check out this issue and documentation about using the Javascript Validation API: https://stackoverflow.com/questions/11866910/how-to-force-an-html-form-to-validate-without-submitting-it-via-jquery
https://www.w3schools.com/js/js_validation_api.asp

[gselderslaghs]

My proposal would be to resume work on this issue. The most desired approach towards accessibility would be:

• Javascript validation
• HTML5 validation (in case Javascript is disabled on the end-user's device)
• Server side validation (which is basically not intended for the Materialize framework)