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
([EMAIL PROTECTED])
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/
