Grow your CSS skills. Land your dream job.

WebKit HTML5 Search Inputs

Published by Chris Coyier

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

Small, Medium, and Large. That's all you get!

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.


Identical font sizings not indentical.

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;
}

View Demo

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).

Comments

  1. Well done, it’s akready in my favs, thx !

  2. Gibheer
    Permalink to comment#

    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?

    • Permalink to comment#

      opening paragraph:

      It does absolutely nothing in most browsers. It just behaves like a text input. [...] WebKit browsers do treat it a bit differently though

    • Permalink to comment#

      Chrome is a WebKit browser.

    • Permalink to comment#

      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…

  3. Whyzak
    Permalink to comment#

    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.

    • Whyzak
      Permalink to comment#

      Here’s a screenshot.

    • Permalink to comment#

      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.

  4. Permalink to comment#

    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).

  5. Permalink to comment#

    Thanks for the overview on Webkit html5 search inputs. LT

  6. Permalink to comment#

    good work thanks a lot

  7. Permalink to comment#

    thank you:))

  8. Permalink to comment#

    thank you:)) good:))

  9. imma
    Permalink to comment#

    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 :-)

  10. 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.

    • Permalink to comment#

      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.

  11. 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.

  12. Miles Carmany
    Permalink to comment#

    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?

    • Permalink to comment#

      agreed. but where should the line be drawn between OS consistency and designer freedom?

  13. Great article (as always) Chris. Totally will use it on my next project +=]

  14. Permalink to comment#

    Typo in second last codesample:

    placholder should be placeholder.

  15. thanks for sharing

  16. 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.

  17. Richard
    Permalink to comment#

    Thanks Chris… : )

    I new you had some more great info in ya

    You da man

  18. @results? But those aren’t “results”. They’re previously entered searchterms.

    It should be @prevterms or something.

  19. Permalink to comment#

    -webkit-appearance: input btw

  20. Permalink to comment#

    Looks 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 :)

  21. Permalink to comment#

    Nice tricks Chris, Thank you.

  22. Permalink to comment#

    Nice work, Chris

  23. Permalink to comment#

    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!

  24. Permalink to comment#

    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.:)

  25. 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.

  26. Permalink to comment#

    It seems that only -webkit-appearance: none; does not remove the rounded corners on iOS anymore. Adding border-radius: 0; does the trick though!

  27. I tested it with iOS 7 on an iPhone 5 and -webkit-appearance: none; did the trick! :)

  28. Permalink to comment#

    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!

  29. jesudas

    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

This comment thread is closed. If you have important information to share, you can always contact me.

*May or may not contain any actual "CSS" or "Tricks".