Select one ... (check one with "x")
[ ] bug
[X] feature request
We need design/implementation for form validation/error messages for select boxes.
Note this should include multi-selects.
This should also be done in relation to Issue #45
Here is the recommended design for validation on a select list (box)

We are aware the recommendation has the icon on the outside. We carefully looked at both options and chose to have it on the outside due to potential touch target conflicts.
@reddolan: How does the error message appear? On hover or on focus? On input fields it appears on focus.
@adityarb88 I'll let @reddolan confirm but it would have to be either click, hover, or both since it is outside.
I'd say on hover, for a consistent experience.
Hover is problematic because hover on mobile devices cannot be relied upon.
I say it should be on focus, like the other validations.
@mathisscott I agree with you and was about to mention that
Is there a plan for when this, and validation for other form components, will be implemented?
@jacobbutton: This ticket hasn't been prioritized yet. The teams priorities for the next few weeks is pretty much decided. But we will try to look into this as soon as possible. Thanks for checking in.
On the VMware CSP UX team, we have standardized form behavior to disable the submit button until the user has completed all required fields in valid formats. (This behavior has not been defined in clarity, but our team made the decision to standardize our forms as such.)
In this context, select boxes don't need validation, since there are no cases in which a user could enter invalid information. The select box validation would only make sense if:
1)聽Submit button is always active.
2) We choose to inform the user if they have skipped a required select box, or have clicked to open the select options then clicked out of the field without selecting a value.
@nbewley I don't know if I understand the entire experience. I have a few questions:
Thanks @reddolan, agree that cases 2/3 need a closer look. In our case, we will inform the user if they skip the selectbox with an error "[field_name] is required."
Indeed, it appears this is how others implement such patterns. This could be something to consider adding to the Clarity guidelines in the future, should other teams implement this pattern.
@nbewley
how will the user be informed?
by other's implementations are you speaking to the error message being displayed below the form field?

Our implementation alerts the user onblur (tab), showing the clarity error message in the event of an invalid field. We could also implement some behavior if the user clicks the disabled submit button to inform them, although we have not designed such an experience at this point.
By others' implementation of this pattern, I mean:
"If you are performing inline form validation, and the field with the error is clearly marked, the submit button may be disabled until the error is corrected."
I am in agreement with you that since we have implemented inline form validation, we need to clearly mark the selectbox with an error if the user skips the field. Thanks for your input!
Is there an update on this? It is a bit strange not to have validation on essential fields such as a drop down select and textarea!
@hakkio
All of our form designs are going through a design review at this time. So it's actively being worked through our UX team. Please subscribe to this issue to get updates when it moves into development.
Hi Team, Can you please advise if there's any update on this request ?
@rpusarla
This work is currently in-flight. We are re-working the DOM structure of form controls and then applying our changes to input fields. Selects are on the horizon. But will be sometime after input fields.
This is all work that will be in 0.12 or later. We are currently in 0.11.
This has been completed in master.
Hi there 馃憢, this is an automated message. To help Clarity keep track of discussions, we automatically lock closed issues after 14 days. Please look for another open issue or open a new issue with updated details and reference this one as necessary.
Most helpful comment
Hover is problematic because hover on mobile devices cannot be relied upon.
I say it should be on focus, like the other validations.