[whatwg] <input type=search>
ian at hixie.ch
Fri Nov 21 18:14:04 PST 2008
I've added a type=search input type.
There was a lot of feedback asking for this, but it all basically said
nothing more than asking for it and sometimes giving a use case. If I
missed something specific that isn't included below please let me know.
On Fri, 18 May 2007, Matthew Paul Thomas wrote:
> 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.
True. Not sure there's much we can do about that here though.
On Tue, 30 Sep 2008, Andy Lyttle wrote:
> I would like Apple's <input type="search"> adopted as an official
> standard, maintaining Safari compatibility. Attributes are:
This seems redundant with oninput="" (on the control) and onsubmit="" (on
> incremental - if present, onsearch fires on every keypress, and on
> clicking the cancel button; otherwise onsearch fires when pressing Enter
This seems redundant since we have two events for those two cases.
> results - if present, shows a little magnifying glass icon, which helps
> to visually identify the field as a search box
I don't understand why the icon wouldn't always be present.
> results=10 - the magnifying glass functions as a drop-down menu
> containing a history of the last (whatever number) search terms
I don't understand why the UA wouldn't always provide this.
> autosave="foo" - define a unique name to identify the search history (so
> the same history may be shared across multiple search boxes, even across
> different domains)
This seems like something we should consider in general for all text
fields. I'm not sure a domain-specific identifier is the right answer
though. Isn't the "name" field enough?
> At first glance it looks like onsearch (when combined with incremental)
> is identical to oninput, but onsearch fires after a slight delay, so
> that if the user rapidly types multiple characters, the search doesn't
> begin until after a sufficient pause in typing.
The spec requires that of oninput.
On Tue, 30 Sep 2008, Andy Lyttle wrote:
> If I have a form on my site, using a particular autosave string for a
> search field, you can create a form on your site that submits to the
> same CGI URL, with a search field that uses the same autosave string,
> and browsers will know that they should share the search history between
> both forms. This is not a security problem, because the history list is
> not accessible to you (or me).
Actually it can be a security risk if you can trick the user to click
(which isn't that hard in practice).
> I don't see this feature getting a lot of use, but Apple has already
> implemented it, and I don't see a compelling reason not to support it.
> And who knows, if it's supported, maybe someone will think of some
> clever use for it that I haven't thought of, that couldn't have been
> done well without this feature.
That's not enough of a reason to add it to the spec. :-)
On Wed, 1 Oct 2008, Mikko Rantalainen wrote:
> Nils Dagsson Moskopp wrote:
> > the look of the input field could be styled just by a value of "search"
> > for the CSS "appearance". that would have to go through CSS3 WG, but
> > would probabvy be the cleanest approach.
> > http://www.w3.org/TR/css3-ui/#system
> See also: http://lipidity.com/apple/iphone-webkit-css-3
> -webkit-appearance: searchfield;
> It works already in Safari.
> Perhaps we need
> behavior: searchfield;
> in addition?
This would be a CSSWG request; please follow up on this with them.
On Thu, 2 Oct 2008, Benjamin Hawkes-Lewis wrote:
> If HTML5 assumes user agents should rely on heuristics to detect Search
> fields, it should specify those heuristics (rather than forcing
> user-agents to reverse engineer them). Do you have an algorithm you
> would like to propose?
> When it triggers a different interface and functionality in popular
> browsers, explicit markup is unlikely to be accidental and relying on
> explicit markup is preferable to heuristics alone. Hence the existence
> of semantic markup (heading elements, microformats, etc.).
I don't propose to add anything to the spec regarding the autodetection of
search fields; I don't think we need interop on that particular feature.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg