Admin: Create 'Location' & 'Organization' does not throw errors when submitting blank form

[alexi215]

Issue: If a user does not interact with the form and clicks create no errors are thrown at all. Oddly enough the associated tests (locations & organizations) for this situation are passing.

When a location or organization form is partially filled out (incomplete from a validation perspective), clicking create throws errors at the top of the page.

[monfresh]

This is also the browser validation that you are experiencing. The tests use a headless WebKit browser, which bypasses the client-side validation, and therefore allows the form to be submitted. Because the organization name field is marked as required in the HTML, most browsers won't let the form be submitted at all, so the server side validations will never kick in. Unfortunately, it seems some browsers don't include a visual alert that lets you know you didn't fill out a particular field. I know Chrome and Firefox do, but apparently, Safari does not , so we could either get rid of the required attribute or use a JS workaround.

@anselmbradford, what are your thoughts on this?

[monfresh]

I just checked html5test.com in Safari and didn't realize it has such a low score for HTML5 support.

[monfresh]

Here is a good explanation of the constraint validation API, browser support for the various features, and workarounds: http://www.html5rocks.com/en/tutorials/forms/constraintvalidation/#toc-safari

I originally added the required attribute per @anselmbradford's recommendation, but given the lack of support in IE <10, iOS Safari, and the default Android browser, I will remove it until we decide whether or not to include a workaround for the browsers that don't support it.

[anselmbradford]

My recommendation would be to always provide server-side validation first and foremost, then add standards syntax (the required attribute), then add polyfills for browsers we want to support, then add stylistic polyfills for evening out cross-browser UX. The client-side validation is just to prevent the step of having to send the data to the server so it can be rejected. Unless the UX flow of making edits seems wildly different between the supporting and non-supporting browsers, it's okay to include the standards required attribute. Any good polyfill should work on top of the standards implementation and browsers that support the standards should not need to touch the polyfill other than to make the experience consistent between browsers. In this case though because all browsers will fall back to the server-side validation, it's preference as to whether you want an enhanced experience for some browsers and not others while a polyfill is investigated. Theoretically including the required attribute provides further accessibility benefit to things like screen readers, but that's edge case stuff. Bottom line is if it gracefully degrades in non-supporting browsers things are okay.

[monfresh]

@anselmbradford I think you might be misunderstanding the user-facing consequence of including the required attribute. For browsers that don't support it at all, yes, they will fall back to server-side validation. However, some browsers, like Safari, support it, but without the helpful visual alert. If you try it out for yourself in Safari, I think you'll understand the issue. When you submit a form without interacting with any of the fields (such as the "Create new location" form), nothing seems to happen, which can lead to confusion.

You can try it out on the demo site, but you'll need to manually add the required attribute to the location name field via the developer tools. http://ohana-api-demo.herokuapp.com/admin/locations/new

[anselmbradford]

Ahh, I see it's partial support in Safari. Yes then it's not degrading properly and you'd want to remove it as you have.