[whatwg] <input type="search">

[Matthew Paul Thomas]

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://www.widgetbox.com/widget/rounded-search-box>
<http://brandspankingnew.net/archive/2005/08/adding_an_os_x.html>
<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 
the native controls, they sometimes rely on JavaScript, they fall apart 
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 
CSS+PNG+JS imitation.)

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.
<http://urlx.org/brandspankingnew.net/564a7>

> * 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 
for=...> element.

Cheers
-- 
Matthew Paul Thomas
http://mpt.net.nz/