Opened 8 years ago

Closed 7 years ago

#14921 closed enhancement (fixed)

Dijit.Select: Missing dijitValidationContainer breaks look 'n' feel of form validation

Reported by: Paul Christopher Owned by: Douglas Hays
Priority: undecided Milestone: 1.8
Component: Dijit - Form Version: 1.7.2
Keywords: Cc:
Blocked By: Blocking:

Description

Description

If you have a form containing an invalid dijit.Select, on form submission/ form validation, no exklamation mark (dijitValidationContainer) is shown for the element.

Steps to reproduce the issue

Run the attachend test case. Do nothing. Just press "Submit" to trigger the form validation. The selects in the form are empty by default and marked as mandatory. Look at Select1. It is the first form input. It has a tooltip but no warning container. Look at Select2. It's the third form element. It is invalid, too. But the invalidity of the form input is not conceivable for the user at all.

Discussion

From the point of view of usability, I consider this to be a major blocker. User judge an application/ web site by superficial things such as design and basic functionality. They don't care about technical details like WAI ARIA etc. And the missing highlighing of the invalid select widgets is one of the things they might first notice.

Moreover: Setting a dijit.Select as empty and mark it as obligatory is not an unlikely use case, too: By doing this, you want to force the user to consciously make the right decision (instead of setting some default value which can be easily overlooked).

As far as I can see, fixing this is not so easy since the construction principle of dijit.Select and the other widgets is different: Dijit.Select is based on tables, the others not.

For the layout problems of dijit.Select, see http://bugs.dojotoolkit.org/ticket/14850

Attachments (4)

screenshot.png (13.2 KB) - added by Paul Christopher 8 years ago.
testSelect.html (3.1 KB) - added by Paul Christopher 8 years ago.
patchSelect.html (6.5 KB) - added by Paul Christopher 8 years ago.
[CLA]SimpleTextSelect.html (2.4 KB) - added by Paul Christopher 8 years ago.

Download all attachments as: .zip

Change History (10)

Changed 8 years ago by Paul Christopher

Attachment: screenshot.png added

Changed 8 years ago by Paul Christopher

Attachment: testSelect.html added

comment:1 Changed 8 years ago by Douglas Hays

Milestone: tbdfuture
Type: defectenhancement

Patches are welcome

comment:2 Changed 8 years ago by Paul Christopher

IMHO this is not a "nice-to-have" feature: If you look at the above screenshot, the invalidity of Select2 is not visible to the user at all. Form validation is severly visually broken therefore.

I can try to have a look at this, but don't know whether I can come up with a viable solution that adheres to the Dojo coding standards and/or fits nicely into the existing code.

comment:3 Changed 8 years ago by Paul Christopher

I have tried to implement this (see patchSelect.html), but the solution is a dirty hack and doesn't work reliably across browsers.

As far as I could see, dijit.Form.Select stands out from the other dijit controls. Its handling is a bit "clumsy". You cannot specify its size by CSS but on creation only via the constructor. Moreover see http://bugs.dojotoolkit.org/ticket/14850 for other issues concerning the select widget which break the look and feel of forms, too.

Maybe - in the long run - dijit.Form.Select needs to be refactored to use divs only (like FilteringSelect, ComboBox)??? Or does the use of tables has a special semantic meaning as far as accessibility is concerned?

Refactoring it to make it work like ComboBox or FilteringSelect would also fix this issue: http://bugs.dojotoolkit.org/ticket/14917. And the validation stuff could be integrated more easily.

Of course the select widget "works", but I'm not happy with it and all its issues.

Changed 8 years ago by Paul Christopher

Attachment: patchSelect.html added

comment:4 Changed 8 years ago by bill

Select is <table> because the content can be of arbitrary height, as opposed to ComboBox where the height is always equal to the height of an <input>. In other words, if there's a tall icon in the displayed value of the Select, the arrow icon on the right still should be vertically centered.

I don't think you need a dirty hack to implement this, can't you just have a table with three columns (value, validation-icon, and arrow-icon)? Obviously the second column would need to be hidden until the Select was marked as invalid (which in this case just means "required but not filled in")

comment:5 Changed 8 years ago by Paul Christopher

I tried it with a third table element, but could not come up with a working solution. This seems to be quite tricky...

My workaround is to use a simple Select based on FilteringSelect now. SimpleTextSelect "validates" and does not have that many layout issues.

Changed 8 years ago by Paul Christopher

Attachment: [CLA]SimpleTextSelect.html added

comment:6 Changed 7 years ago by Douglas Hays

Milestone: future1.8
Resolution: fixed
Status: newclosed

Fixed by #14850.

Note: See TracTickets for help on using tickets.