Comment 0 for bug 1222787

Revision history for this message
Matthew Paul Thomas (mpt) wrote : No standard error appearance for text fields and other controls

The toolkit does not have a standard error appearance for text fields, other controls, or captions.

The error appearance should be used for fields that you have filled out incorrectly, other controls that have a disallowed state, and captions explaining the problem with individual controls.

Examples:

* If you choose a time in a restaurant reservation system, submit the request, and the server responds that that time is unavailable, the time picker should retain the previous value (so you can see what you chose) but should have the error appearance. A caption should appear below it explaining the problem: for example, “Sorry, 7:30pm is unavailable. Try earlier or later.".

* Similarly, the validity of a checkbox, radio button, switch, etc selection might be too complex or volatile to check on the client side of an app. If the server side responds that the selection isn't allowed, the control should adopt the standard error appearance, and a caption below if necessary.

* Changing the SIM PIN requires entering the current PIN. The phone can't check the correctness of the current PIN with every character you types, because trying an incorrect PIN three times or so will lock the SIM. Instead, it is checked only once you submit the dialog. *Then* if the current PIN turns out to be wrong, that field should get the standard error appearance (maybe a pale pink background, and/or a maroon border, and/or a brief flash), and an explanatory caption below it.

* All the captions mentioned above should have their own consistent error appearance. (Maybe maroon text.)