abide: provide ability bypass validation on certain submit actions

[tchollingsworth]

What is missing?

The ability to bypass Abide validation for certain submit actions, e.g. an Abide equivalent of the formnovalidate attribute in HTML5.

Why is it important?

It is ofen used to implement Save and related actions where invalid input is acceptable.

Possible Solution

s/$('[data-abide] [type=submit]')/$('[data-abide] [type=submit]:not([data-no-validate])/

Context

I was attempting to use Abide with a form where HTML 5 validation was already bypassed with formnovalidate on certain submit actions,

Your Environment

• Foundation version(s) used: 6.4.3, 6.5.0-rc.2

Checklist (all required):

• I have read and follow the CONTRIBUTING.md document.
• There are no other issues similar to this one.
• The issue title is descriptive.
• The template is correctly filled.

[SassNinja]

@tchollingsworth would describe the use case for this feature more detailed?

I don't understand what you mean with 'save and related actions'. If you use Abide on a form it should validate on submit. Otherwise validation would be quite useless because the user may submit invalid data.

[tchollingsworth]

The HTML standard explains:

[The `formnovalidate`] attribute is useful to include "save" buttons on forms that have validation constraints, to allow users to save their progress even though they haven't fully entered the data in the form. The following example shows a simple form that has two required fields. There are three buttons: one to submit the form, which requires both fields to be filled in; one to save the form so that the user can come back and fill it in later; and one to cancel the form altogether.

<form action="editor.cgi" method="post">
 <p><label>Name: <input required name=fn></label></p>
 <p><label>Essay: <textarea required name=essay></textarea></label></p>
 <p><input type=submit name=submit value="Submit essay"></p>
 <p><input type=submit formnovalidate name=save value="Save essay"></p>
 <p><input type=submit formnovalidate name=cancel value="Cancel"></p>
</form>

https://html.spec.whatwg.org/multipage/form-control-infrastructure.html

[SassNinja]

This is quite theoretical.

Imo if you wanna save the form it should be done automatically (ajax).
But even if you liked to bind this to a button I'd suggest to add a listener on the button instead of actually submitting (and therefore validating) the form.

Thus I still don't see a real use case.
Have you faced this issue in one of your projects?

[warriotox]

Hi, we are facing this issue. We have a multiple step form that isnt ajax. It has back-end validation but we wanted to add to it also front-end validation using abide. The scenario is, user fills in 3 fields on step one, clicks next, gets to step 2 with 15 fields, realizes he entered something wrong on the first step and wants to go back. Clicking the previous button (type="submit") triggers the abide validation and now the user needs to fill in all the fields on the screen before hes able to go back to the first screen... For this exact reason they introduced the formnovalidate attribute with HTML5's front-end validation https://www.w3schools.com/tags/att_input_formnovalidate.asp. If you dont see a real case its great, but there definitely are use cases for this in older systems where everything isnt ajax. The fact that the people who put together the HTML5 spec thought of it, should be enough evidence to support its usefulnes.. Also the fact that its a common html5 attribute and you dont support it natively in Foundation and dont even provide anything to replace its functionalty is, well not great.. If anything you should add to your abide documentation the best way to re-create the functionaly of this so people who do still want to use abide, but need this can use it. Right now my only course of action is to either remove abide, or remove back/cancel/next buttons from the forms. Also if you think Im making the use case up, here's the form https://www.idc.com/cee/events/64662-web-developers-event-for-automatic-tests-on-idc-com-do-not-update-manually/registration

Can you please recommend something, like a JS function that I can use right now to implement the formnovalidate logic even when its not natively supported by foundation?

PS: the reason the back/next buttons are type submit and not just some JS function that uses browser history is so that whatever the user has typed in on the second step befor hitting back is still there when he comes back to it from fixing whatever he needed to fix on the first step. We've tried using window.history.back() but only some browser keep the input values through that so that is not a replacement and we really do need to submit the form on back/next.

[SassNinja]

@warriotox I understand your use case.

So Abide should look for [type="submit"][formnovalidate="formnovalidate"] and skip validation on click, shouldn't it?
(less comfortable alternative would be a new method to disable validation)

Can you please recommend something, like a JS function that I can use right now to implement the formnovalidate logic even when its not natively supported by foundation?

You could destroy the Abide instance on clicking your back button and submit the form via JS afterwards. But of course that's more a workaround than a solution.

[warriotox]

Yes exactly. Thank you for the quick reply! What is the process now to get it implemented? Will it be added to foundation 6 or next full pledge version?

And for the workaround thats is exactly what I did, I just added it to foundation JS so it seems like its working natively. I rewrote the on submit function like this.

 .on( "submit.zf.abide", function( e ){
		var $btn = $(document.activeElement);
		if (
				/* there is an activeElement at all */
				$btn.length &&

				/* it's a child of the form */
				t.$element.has($btn) &&

				/* it's really a submit element */
				$btn.is('[type="submit"]') &&

				/* it has a "formnovalidate" attribute */
				$btn.is('[formnovalidate]')
		) {
			return true;
		}else{
			return t.validateForm()
		}

[warriotox]

Just realized I dont need to destroy abide and call the submit as I previously thought. Updated the code above. Just returning true is enough.

[SassNinja]

@warriotox we've stopped accepting new feature for Foundation v6 as we're focusing on v7.

However since this a a minor change that might be quite helpful for you and others I've made exceptionally a PR that adds the feature in talk:
#11613

[warriotox]

@SassNinja Thank you!

Looking through the changes I see that you will use your functionality to turn of the validation and then the submit will be triggered with "this.$element.submit();" which is similar to what I had there and this was throwing an error into the console "maximum call stack size exceeded". I have then replaced this with just returning true which allowed for the native submit to work on its own. When you are testing this, if in Chrome console you set it to preserve log between redirects, check whether it throws that error or not. If it doesnt nevermind what I wrote, if it does maybe consider the implementation I went with.

Also you say the enter key should be supported. Yes, when the user focuses the formnovalidate submit button and clicks enter it should not trigger the validation. But if the user clicks enter in any of the form input fields or with the next/finish submit button the abide validation needs to kick in.

[SassNinja]

But if the user clicks enter in any of the form input fields or with the next/finish submit button the abide validation needs to kick in.

That depends all on your markup: if the formnovalidate submit comes before the other submit pressing Enter will skip the validation. That's the native behavior and would be the same in my emulation.

[warriotox]

I see, you are correct, just tested it as well. With how I implemented the "workaround" functionality it doesn't happen and I must say I like that way better. You can try it here Just fill in anything on the first step, then on the second focus any of the input fields and click enter and it will trigger abide, but clicking on "cancel" or "back" with the mouse, or using the tab key to focus them and hitting enter will bypass the validation. Guess I might just keep the custom implementation then. If you implement it as you have it now I would have to move the cancel/back buttons down in HTML and somehow re-position them with CSS (probably with flex order but that seems counterintuitive). The native behavior is not great for this use case. But I do understand that is how you should be implementing it..