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