HTML and CSS Reference
In-Depth Information
This works, but only for the currently focussed input. We want
something more: we want the invalid fields to be styled differ-
ently only after users have entered some content.
Because of these problems, Firefox uses an alternative pseudo-
class called -moz-ui-invalid which provides a much better
user experience, as the Mozilla Developer Center describes:
“If the control is valid when the user starts interacting with it,
the validity styling is changed only when the user shifts focus
to another control. However, if the user is trying to correct a
previously flagged value, the control shows immediately when
the value becomes valid. Required items have the pseudo-class
applied only if the user changes them or attempts to submit
an unchanged valid value.”
Other pseudo-classes available include :in-range and :out-of-
range and :indeterminate (the latter would apply to a number
input with min/max that is currently empty).
While we wait for a fully specified, properly sanctioned way of
consistently styling all the other things in all browsers, there are
a few vendor-specific tweaks and tricks that can be used. We've
already seen Mozilla's ui-invalid , for example. WebKit offers us
ways in which to style the validation error message bubbles (see
Figure 3.2):
::-webkit-validation-bubble{}
::-webkit-validation-bubble-top-outer-arrow{}
::-webkit-validation-bubble-top-inner-arrow{}
::-webkit-validation-bubble-message{}
Currently, there aren't many cross-browser methods of chang-
ing the look and feel of HTML forms. This isn't necessarily a
bad thing. Your branding people will, of course, lament that
placeholder text isn't in corporate purple and orange. But it's a
usability and accessibility win; although it's tempting to style the
stuffing out of your form fields, whatever your branding people
say, it's better to leave forms as close to the browser defaults as
possible. A browser's slider and date pickers will be the same
across different sites, making it much more comprehensible to
users. It's much better that a date picker on site X looks and
behaves the same as a date picker on site Y or site Z.
And, by using native controls rather than faking sliders and date
pickers with JavaScript, your forms are much more likely to be
accessible to users of assistive technology.
 
Search WWH ::




Custom Search