[whatwg] <input type="search">
Matthew Paul Thomas
mpt at myrealbox.com
Thu May 17 23:53:09 PDT 2007
On May 18, 2007, at 12:43 PM, Lachlan Hunt wrote:
> * class="search"
> The aim of this one was to be able to indicate the form specifically
> used for searching. This would then allow UAs, especially assistive
> technology, to implement keyboard shortcuts or other mechanisms for
> taking the user directly to the search form. role="search" is
> provided by the role attribute spec for a similar purpose, and Safari
> also has <input type="search">. I would prefer the new input type
> because it also has direct benefits for regular users, not just those
> with assistive technology.
I agree, why not add <input type="search">? The use cases are:
* Better accessibility, as described above by Lachlan.
* People often scan Web pages looking for "the little box where I can
type". <http://www.useit.com/alertbox/20010513.html> If site search
fields were visibly different from other text fields, and different
*in a consistent way across sites*, that would make people faster at
using those sites.
There are also ill effects from it *not* being standardized. Web
authors often use brittle CSS in an attempt to emulate the Mac OS X or
Windows Vista search field look.
<http://urlx.org/search.live.com/f3835> (see the top of the page)
They're brittle in the sense that they have cosmetic differences from
when the page is zoomed, and/or they don't zoom at all. (Safari's
implementation in 1.3/2.0 also doesn't zoom, but that could be fixed
much more easily in WebKit -- if it hasn't been already -- than in a
I can think of one potential problem, that being Web authors trying to
use <input type="search"> for fields that aren't search fields because
they think it looks cool (and because they don't use assistive aids
themselves, so they don't realize the silliness). That problem would be
inversely proportional to how much browsers made the field behave
unalterably like a search field.
> * class="error"
> The original idea for this was for indicating error messages,
> particularly related form fields. The problem is that screen readers,
> when in forms mode, only read the content of form control labels,
> which has resulted in authors having to write any error messages
> within labels, which is kind of a hack. Labels and error messages
> should be able to be separated and providing a way to specifically
> indicate them would allow screen readers to indicate their presence to
> the user and read it on request.
Maybe that should be addressed (in Web Forms 3?) with a specific <error
Matthew Paul Thomas
More information about the whatwg