Email validation inconsistant - Submit button not disabled about bouncer HOT 7 CLOSED

I understand that emails of the form a@b are perfectly valid in the spec

I know that the spec allows emails like that, but outside of internal email addresses at companies, that's not what real email addresses look like. You're correct in your guess that Bouncer uses a different pattern to detect valid emails. It specifically looks for a TLD.

You're certainly welcome to pass in a custom pattern for emails, though, if you want something less restrictive.

It's unclear what "submit button not disabled" in the title means relative to this issue, though. Can you clarify?

from bouncer.

"submit not disabled" just means the standard disabled button as you would style with form:invalid input[type="submit"]
In the code/screenshot as above 'disabled' is styled grey, 'active' is orange.
Thats the only extent of the bug, 'invalid' is somehow not being applied to the form (but you still cant submit... ie its just a visual bug)

from bouncer.

I did try to pass in some alternate patterns with the same result (there seems to be quite a range of different regexes)
Are you able to post a pattern that would be the equivalent of whats used internally?

from bouncer.

Ah yes, bouncer doesn't disable any of the buttons on error, though that's certainly something you could extend using the event hooks.

Adding a class to the form is not a bad idea, though. I like that. Will open a new ticket for that as well.

Here's the regex pattern used natively by browsers, per this website:

/^[a-zA-Z0-9.!#$%&’*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$/

from bouncer.

I realise now that this is just chrome behaving correctly - in html5 terms a form with email a@b IS valid, and so chrome correctly applies the 'active' css to the submit. (only that bouncer marks the field as invalid as per its rules)
As you mentioned, a js-applied class on the form could be used as a css hook for this state (but it would have to override the rules as described above if you want it all to work no-js)

Thanks for your time!

from bouncer.

I gave this a bit more thought, and decided not to add an error class on the form itself.

Bouncer validates individual fields on blur (as opposed to on submit with native form validation), and for fields with errors, it revalidates in real time as the user types.

In order to properly remove an error class from the entire form, Bouncer would need to constantly query the DOM to see if any other fields have errors.

It appears as though your issues are caused by hooking into native validity state for styles instead of (or on top of) using the class hooks Bouncer provides.

I would recommend using the [novalidate] attribute as a style hook in your CSS to suppress those styles after Bouncer initializes. Alternatively, you could add a class to the form after the bouncerInitialized event fires.

from bouncer.

I ended up passing the following pattern:
pattern="[a-zA-Z0-9!#$%&'+/=?^_`{|}~.-]+@[a-zA-Z0-9-]+(.[a-zA-Z0-9-]+)"
using the 1.4.1 version of Bouncer, this makes Bouncer allow emails of the form a@b so in synch with native html5 validation.
Lets see if the client complains! :)

from bouncer.