[whatwg] <input type=search>

[Ian Hickson]

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:
> 
> onsearch="foo();" - JavaScript function called when the user initiates a 
> search

This seems redundant with oninput="" (on the control) and onsubmit="" (on 
the form).


> 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.   `._.-(,_..'--(,_..'`-.;.'