A while back Trent Walton wrote about using
-webkit-appearance to override the default styles of form elements in Safari on iOS devices (iPad, iPhone, and iPod Touch). Safari on iOS adds an inner shadow to the top of input text fields. It can only be overridden by setting
caret, or by adding a background image to the field.
Sounds like an easy fix, right? But if you didn’t read the comments on Trent’s article, you might have missed two important bugs* connected to using
-webkit-appearance to remove the inner shadow:
- If you use
caret, it removes not just the inner shadow but also the borders on desktop versions of Safari and Chrome (as well as the beta version of the WebKit-based browser on the TouchPad tablet).
- If you use
none, it removes the inner shadow and leaves borders alone, but it disables focus styles on iPad.
In the case of the missing focus, I haven’t been able to confirm this myself; I don’t have an iPad, but the people I’ve asked to test it for me (thanks Josh!) have said the focus styles do show up, even when
-webkit-appearance: none is set. Perhaps it’s a case of the version of iOS in use, perhaps the person who reported this bug in the comments to Trent’s article was simply having a problem with his individual machine, or perhaps there was something else in the CSS that was truly responsible for the problem. So it’s still not clear to me whether the second bug I listed above is really present. Do any of you iPad users have a problem seeing the red outline on focus in my test page?
If both of these bugs are truly present, they severely limit the circumstances in which
-webkit-appearance can be used to remove
inputs’ inner shadows. Luckily, we can use a background image instead of
-webkit-appearance to remove the shadow. But what if you don’t want any background image to show? Simpleâ€”make the background image invisible. Some smart people on Stack Overflow suggested a couple ways to do just that:
- Tile a transparent GIF as the background image.
- Add a CSS3 gradient that runs from transparent white to transparent white.
I think the gradient option is ideal because it doesn’t require an extra hit to the server to retrieve the transparent GIF. And there’s no need to worry about lack of browser support, since the only browsers we want to apply the gradient are Safari on iOS.
Here’s what the CSS would look like for the gradient:
background-image:-webkit-gradient(linear, 0% 0%, 0% 100%, from(hsla(0,0%,100%,0)), to(hsla(0,0%,100%,0)));
background-image declaration, using the
-webkit-gradient function, is what will actually work in Safari on iOS today. The second declaration using
-webkit-linear-gradient is there for future compatibility; WebKit has recently updated its gradient syntax to match the W3C specification. These syntax changes are in nightly builds and will make it into live versions of Safari and Chrome sometime soon, and you want your CSS to be prepared.
Most of this is not new informationâ€”it’s almost all in Trent’s article and comments and the Stack Overflow page. But I wanted to put it all together in one place, clearly explained, for easy reference. Hope it helps you out!
*I don’t actually know that these are true bugs. But they sure seem like bugs to me, and in any case, they certainly need some working around!