HTML and CSS Reference
In-Depth Information
So what does this buy you? Well, fi rst and foremost, you're
future-proofi ng your code for that time when all browsers sup-
port these hugely useful additions to forms. Secondly, you buy
a usability and accessibility win.
Styling new form fi elds
and error messages
Whenever we present the new intelligent form fi elds at confer-
ences, someone asks us how you can style these new fi elds.
Yo u c a n d of s of m e b a s i c s t y l i n g of n m of s t of f t h e n e w c of n t r of l s :
fonts, colours, and the like. Some aspects of the CSS Basic User
Interface module ( ) apply to these
elements—for example, the :invalid and :required pseudo-
classes are applicable. But if you want to make all weekends
in the date picker green, or make error messages purple, you
can't. The selectors and CSS hooks for these parts of the new
form controls haven't been specifi ed yet.
This isn't a bad thing. Your branding people will, of course,
lament that placeholder text isn't in corporate colours. But it's a
usability and accessibility win. Although it's tempting to style the
stuffing out of your form fields (which can, incidentally, lead to
formal-weirdness/ ), whatever your branding people say, it's bet-
ter to leave forms as close to the browser defaults as possible.
A browser's slider and date pickers will be the same across dif-
ferent sites, making it much more comprehensible to users. It's
much better that a datepicker on site X looks and behaves the
same as a datepicker 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