[whatwg] <input type="search">
hyatt at apple.com
Fri May 18 00:13:23 PDT 2007
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).
(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
> type". <http://www.useit.com/alertbox/20010513.html> If site
> fields were visibly different from other text fields, and
> *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
> 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.
>> * 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.
> Matthew Paul Thomas
More information about the whatwg