One of the new types of inputs in HTML5 is search
.
<input type=search name=s>
It does absolutely nothing in most browsers. It just behaves like a text input. This isn’t a problem. The spec doesn’t require it to do anything special. WebKit browsers do treat it a bit differently though, primarily with styling.
A search input in WebKit by default has an inset border, rounded corners, and strict typographic control.
The Styling Limitations
WebKit has big time restrictions on what you can change on a search input. I would guess the idea is consistency. In Safari particularly, search fields look just like the search box in the upper right of the browser. The following CSS will be ignored in WebKit “no matter what”, as in, you can’t even fight against it with !important
rules.
input[type=search] {
padding: 30px; /* Overridden by padding: 1px; */
font-family: Georgia; /* Overridden by font: -webkit-small-control; */
border: 5px solid black; /* Overridden by border: 2px inset; */
background: red; /* Overridden by background-color: white; */
line-height: 3; /* Irrelevant, I guess */
}
In other words, be extremely cautious about using any of those CSS properties on a search input unless you are OK with the search input looking very different in other browsers.
Allowed styling
The following CSS works as expected. The last three, in my opinion, should probably locked in like the properties above as styling those properties almost always looks worse than if you didn’t.
input[type=search] {
color: red;
text-align: right;
cursor: pointer;
display: block;
width: 100%;
letter-spacing: 4px;
text-shadow: 0 0 2px black;
word-spacing: 20px;
}
Busted styling
Be careful not to use text-indent
on search inputs. The results are quite weird and inconsistent. Here is one example:
Sometimes the text is below like this. Sometimes it’s not visible at all. It appears to be related to elements around it as well as how much indent it has (low values sometimes work fine).
Show Previous Searches
This isn’t documented anywhere that I know of nor is it in the spec, but you if you add a results
parameter on the input, WebKit will apply a little magnifying glass with a dropdown arrow showing previous results. (Thanks to Mike Taylor)
<input type=search results=5 name=s>
The integer value you give the results
attribute is how many recent searches will appear in this dropdown, if there are that many.
I really like the little magnifying glass. It drives home the searchyness of the field, but I’m calling the functionality itself rather janky. On a page reload recent searches clears, so that dropdown will almost always say “No recent searches”, unless you have implemented some kind of Ajax search (and even that I haven’t really tested).
Update: You can use the autosave
parameter to persist the values in the dropdown menu across page loads.
<input type=search results=5 autosave=some_unique_value name=s>
Size Restrictions
There are only three different “sizes” that WebKit search inputs can be, and it is determined by the font-size you declare on them.
Resulting Size | CSS font-size |
---|---|
Small | <= 10px |
Medium | 11px – 15px |
Large | >= 16px |
This small, medium, and large business can be extremely frustrating, as even setting identical font values, at the minimum for a “bump”, you’ll see font size difference across browsers.
Notice the (x) on the right hand side of the search inputs on the WebKit side. That is an additional feature of these search inputs in WebKit. If the input has any value (not a placeholder, a real value) the (x) will be present which is a functional UI control for clearing the input.
Speaking of placeholder text, search inputs are a great candiate for that.
<input type=search results=5 placeholder=Search... name=s>
And in case light gray isn’t your cup of tea, you can style the placeholder text:
::-webkit-input-placeholder {
color: orangered;
}
Styling Search Graphical Widgets
For instance, the little (x) button that shows when you have text entered into a search input. That can be styled by first removing the -webkit-appearance on the special pseudo-like-element (are we calling them that?) and then applying your own styling:
input[type="search"]::-webkit-search-cancel-button {
/* Remove default */
-webkit-appearance: none;
/* Now your own custom styles */
height: 10px;
width: 10px;
background: red;
/* Will place small red box on the right of input (positioning carries over) */
}
Special JavaScript Events on Search Inputs
I’ll update this when I have more information, but for now, I saw this comment on Ajaxian from “maccman”:
There are also some custom events too – such as ’search’ which fires when the user pauses typing (set ‘incremental’ to true).
Nice summary Chris. I used this in a recent project. You can get around the styling limitations with the following CSS:
I can’t take credit for that either, just remembered where I found it… CSS Webkit Appearance
It’s not enough. To get rid of superfluous padding, you need to disable WebKit’s proprietary pseudoelements like this:
I usually set the type of the search input to textfield. That seems to solve a lot of my styling issues: -webkit-appearance: textfield;
input[type=search] {
-webkit-appearance: textfield;
}
Well done, it’s akready in my favs, thx !
I just tried your demo with chrome 7 and 5 and it looks not the way you described it here. May be it’s just something Safari does?
opening paragraph:
Chrome is a WebKit browser.
I was playing with search inputs recently and you’re correct on Chrome – the particular feature was recently implemented in Webkit, so I believe that Chrome still needs to upgrade to the latest webkit version to have it (Chrome doesn’t have text stroke yet either, though the latest Safari does).
I like the feature of the search input, but I wanted pixel-perfect style and I wasn’t able to get it so I ultimately killed it. Might go back at some point but not just now…
Tried your Demo on Chrome 5 and Safari 5 on Windows XP and it looks not as refined as on Mac. Seems as though the rounded edges don’t seem to work on Windows.
Here’s a screenshot.
This. The corners are not rounded on Windows XP in either browser. Would be very interested to know if they are only rounded on Safari 5 Mac. i.e. I am curious if they are also rounded in Chrome 5 Mac or in either browser on other Windows platforms.
As pointed by Ben, most of those CSS issues can be resolved by changing the -webkit-appearance property (to none or textfield).
I recently used this on a project :
input[type=”search”] { -webkit-appearance: textfield; }
I just remember an issue about inner box-shadow with Chrome (Windows versions only).
Why is it that when webkit does something that goes against the spec and itself behaves different in different versions it’s treated as ok, but when other browser engines do this they are considered doing something very wrong and something to be shunned?
Dave, I have to agree. If this were an IE behavior people would be coming out of the wood work to bash it. However, Apple uses Webkit so somehow it’s ok.
…because when webkit does it it’s usually functionally sound and an improvement versus MicroSoft doing things differently simply because they can.
Well put – when webkit does something different it’s to improve, when MicroSoft does something different it’s to try and make it so everyone does what they do. Unfortunately, for years and years they got their way!
When I read the article is I was kind of annoyed, but maybe since webkit gets so many other things right, it’s easier to forgive?
I think this is a good point and interesting discussion to have. I think in this particular case, it’s technically an optional addition you can choose to use or not use at your discretion. The implementation also isn’t broken or against the spec, which is mostly what IE gets shit for. IE does have some implementations that other browsers don’t have that it does pretty well. For example the “orphans” property works great (prevents single words on a new line at the end of blocks of text) works only in IE and Opera right now, and I use it all the time. So the shit should almost be flying in the other direction in this case.
Thanks for the overview on Webkit html5 search inputs. LT
good work thanks a lot
thank you:))
thank you:)) good:))
Hiya
I liked the article but you keep comparing Webkit browsers to something – what is it?
I’m guessing IE or firefox, but it could be a whole group of browsers – could you clarify, pls?
Thanks :-)
“results” is documented (briefly) there: http://developer.apple.com/safari/library/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#//apple_ref/doc/uid/TP40008058-results
You know what, that just kinda sucks. So great, the search elements is cool, but all that styling limitation… who’s idea was that? Very dumb in my opinion.
I have to agree about the styling limitations. I don’t care if a browser does something differently by default, but it’s a problem when I can’t apply css to something without jumping through hoops.
As others have stated, the way around this is setting the -webkit-appearance. This technique also works for other input types, such as checkboxes or radio buttons.
Hmm…
I’m torn weather or not this is good or bad behavior (in part or in full). As others have pointed out, my slight pro-Apple bias may be keeping me from just jumping all over this as bad. BUT, I also remember back in the early days of Firefox, how there was much discussion about it being bad practice for authors to change the appearance of anything that is window chrome, so that it remains consistent with the OS and particular Browser conventions. (IE scrollbars i’m looking at you).
I’ve also read a bit on reset stylesheets taking care not to mess with forms for similar reasoning. If Apple is using this line of reasoning to justify what they are doing with “search” forms, then I think I can accept it.
Some of us really like to be able to control everything, but I can see the other side too, where User Agent vendors want their platform to do certain things and be able to show off the features they consider important.
Apple might be focusing on OS consistency and their particular design aesthetic. Firefox on extensibility, Chrome on pure speed, Opera on being better than IE and still having a ton of features and lots of toolbars built in. IE on….pushing Silverlight?
agreed. but where should the line be drawn between OS consistency and designer freedom?
Great article (as always) Chris. Totally will use it on my next project +=]
Typo in second last codesample:
placholder should be placeholder.
thanks for sharing
As others have said, just set the webkit-appearance to none. But there’s a couple of other properties you need to change.
http://anthonyshort.com.au/post/1016795820/styling-the-search-input-in-webkit
Webkit changes the box-sizing property on search inputs as well, so you need to reset that, and you only need to disable a single pseudo-element to remove the extra padding.
Thanks Chris… : )
I new you had some more great info in ya
You da man
@results? But those aren’t “results”. They’re previously entered searchterms.
It should be @prevterms or something.
I agree.
-webkit-appearance: input
btwLooks great but will it work with the old ie 6 or even 7? I tried to customize inputs and always find myself in big trouble when it comes to ie, maybe html5 will break the barrier, I hope so :)
Nice tricks Chris, Thank you.
Nice work, Chris
In Safari, you can maintain the list of Recent searches across browsing sessions.
Just add autosave=”Any Unique Identifier”.
Chrome should get to implementing this usability feature pronto.
The padding , background and border bugs screwed me for over half an hour trying to get it to work …
Wish I could seen your blog post earlier!
Nice blog and also useful with developers and also designer to use the webkit and make the perfect search box with recent searches functionality like autosuggestion with different browsers.
Thanks.:)
This is great information on how to create a better search. What I’m curious about though is how you are using WordPress to search different areas on your site.
It seems that only
-webkit-appearance: none;
does not remove the rounded corners on iOS anymore. Addingborder-radius: 0;
does the trick though!Be aware of the following issues:
http://blog.yorkxin.org/posts/2013/07/03/universal-hover-triggers-double-tap-bug-in-ios-safari
and
http://help.symbolset.com/customer/portal/questions/828932-conflict-with-symbolset-ios-search-inputs-and-javascript
I was surprised by how many problems a simple input can cause on iOS Safary…..
I tested it with iOS 7 on an iPhone 5 and -webkit-appearance: none; did the trick! :)
Does anyone know if it’s possible to change the styling on the previous search history list that comes up?
It’s pretty annoying when it’s a glaring white background on a nice subtle dark site!
Hi Chris,
i have one other of requirements.
I want see cancel button in search field. its visible in desktop webkit browsers.
But somehow, i can see in this in iOS safari browser.
can you tell what might the issue ?
Regards,
Jesudas