Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

outline-offset for input[type="search"] in WebKit #19

necolas opened this Issue Jun 24, 2011 · 5 comments


None yet
5 participants

necolas commented Jun 24, 2011

By default WebKit sets a negative default outline-offset on certain form elements:

select:focus {
    outline-offset: -2px

And resets it to 0 for specific input types:

input[type="file"]:focus::-webkit-file-upload-button {
    outline-offset: 0

normalize.css sets input[type="search"] to have the appearance of a textfield so that styles can be properly controlled. However, the outline-offset is different to that for a default input.

The options are:

  1. Set input[type="search"] to use outline-offset: -2px so that it matches the default text input. This has makes no difference if the appearance isn't set to textfield (so it's "safe" either way). However, the outline position still varies between text input and all the submit button types.
  2. Set all input, select, textarea to use outline-offset: 0 but have the halo focus ring not wrap quite so snuggly around textarea and text inputs.

Another consideration is that if the outline-offset is left at -2px for some elements, it can look a bit odd if you use a custom focus outline.

I would go with option 1, especially since I didn't notice any outlines for submit button types, so I'm not sure what you are referring to (testing in Safari 5 in Windows).

I also don't think that custom focus outlines should be a consideration since any oddities can be fixed as part of the custom style.

The problem applies not only to custom outlines on :focus pseudo input elements, but to outlines on input elements in general. A person not familiar with outline-offset might be confused when the outline caused by input { outline: 1px solid blue } shrinks in Webkit when giving focus to an input field.

Setting outline-offset: 0 on input:focus, select:focus, textarea:focus unfortunately affects the default appearance in Safari (but not in Chrome). So going with option two should probably be followed up by further normalizing the default input:focus, select:focus, textarea:focus styling.

Option 1, the cost is lower.

deesx commented Nov 7, 2012

Useful. thx


necolas commented Jan 16, 2014

Not going to try and juggle the issues here. Better to leave a tiny visual difference in Safari/Chrome and let library code handle any customizations that might be wanted.

@necolas necolas closed this Jan 16, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment