[whatwg] <input type="search">

[David Hyatt]

If <input type=search> were to be standardized, Apple would need this  
done in a way that would be backwards-compatible with our current  
syntax.  Otherwise we'd be forced to require an opt-in mode for HTML5  
(and that is really not something we want to have to do).

dave
(hyatt at apple.com)

On May 17, 2007, at 11:53 PM, Matthew Paul Thomas wrote:

> 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/
>