Normalize.css: Remove rounded corners on input elements in Mobile WebKit

[iamkeir]

Spotted that Mobile WebKit gives input elements a border-radius - would the removal of this be within normalize's remit?

http://jsfiddle.net/iamkeir/FnN5u/

[dargullin]

There's also a box-shadow.

This code should help:

-webkit-border-radius: 0;
border-radius: 0;
-webkit-box-shadow: none;
box-shadow: none;

[necolas]

would the removal of this be within normalize's remit

Possibly. In general, I try to keep normalize focused on things that can be a problem - like the inability to style elements, spacing and display inconsistencies, etc. Some aesthetic differences are OK as it's not really feasible or desirable to get pixel perfection across all browsers and platforms.

But there might be some good reasons to do this, if it can be done without side effects. Thanks for reporting this.

[iamkeir]

No problem, thanks for the response.

[necolas]

Using iOS simulator, I couldn't actually get rid of the box-shadow.

[medoingthings]

Using iOS simulator, I couldn't actually get rid of the box-shadow.

-webkit-appearance: none; should do the trick

[necolas]

-webkit-appearance is too destructive, it remove all the other default form styles. I'll remove the border-radius, but leave the rest alone.

[necolas]

Actually, there's no nice way to do this without affecting lots of different input types (radio/checkbox look the same without border radius, input buttons lose a lot of styles, etc). So, another wontfix / do this in your component css i'm afraid.

[somsekhar]

The below css works for me.

input {
-webkit-border-radius: 0;
border-radius: 0;
-webkit-box-shadow: none;
box-shadow: none;
}

[garrettw]

That code was already suggested and rejected for the above-stated reasons.

[adamwathan]

input buttons lose a lot of styles

Curious if anyone knows the specifics of what @necolas was talking about here, or knows of any other issues besides the radio buttons losing their border radius?

Considering a simple reset like this in one of my own projects and trying to figure out if there are unintended consequences I need to worry about:

input,
button,
select,
textarea {
  border-radius: 0;
}

[type="radio"] {
  border-radius: 50%;
}

[gouch]

What @necolas was getting at, I think, is that controlling form element appearance is an all-or-nothing project. You can set some color and font properties and be okay, but if you start touching style/layout now you’ve signed up for a lot of work — with risk. (Think borderless white checkboxes on a white page (i.e. invisible) in the one browser+OS combo you didn’t check.)

You have to look at each form element in each browser on each OS, because those elements inherit/mimic styles from the OS. You get that for free, but if you mess around, at some point the browser will toggle off its attempt and let you have at it. (I think this is because something like a radio isn’t just a styled up div but is a widget coming from the OS.) That means you have to re-specify every property from scratch and then do a thorough browser check.

For example, the code above that’s supposed to just change the border-radius causes Mac Firefox to drop additional parts of its default styling, so now I have to re-specify the borders I want. Maybe I would/should be doing that anyway, but that's why form element styling is all-or-nothing.

Also, I would say never apply CSS to the bare input element — those aren’t just text: they are buttons, sliders, date pickers, and more. There’s only like seven “text-like” inputs, so I always specify those directly (e.g. input[type="email"], input[type="number"], …, textarea)

[garrettw]

[offtopic] for less specificity and CPU cycles I usually don't target the element name unless I need to -- so just [type="submit"], [type="text"], etc. [/offtopic]