IE 7 button text redraw bug

Posted by & filed under Articles.

I’ve run into an IE 7 bug that I’ve been unable to fix. I’m hoping some of you, dear readers, can help me figure it out.

I’m working on some styled buttons, created with the <button> element and some pretty basic CSS. In IE 7, if you scroll down the page so that the buttons move out of the viewport, then scroll back up to reveal them again, you’ll see lines of missing pixels drawn across the text of the buttons. It varies each time you scroll, so sometimes you won’t see any lines, and occasionally the entire text will disappear. The lines appear most often with the buttons with the largest text, but I think this is mainly just due to there being more pixels there to draw lines through, increasing the likelihood that IE 7 can screw it up. Hovering over the buttons or refreshing the page restores the text.

You can see a screenshot of the bug below, and view the bug live in IE 7 in my test page.

The buttons in IE 7 have lines drawn through their text, as if little strips of the text were erased.

(more…)

Bug fixes for removing the inner shadow on iOS inputs

Posted by & filed under Articles.

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 -webkit-appearance to none or 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:

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

  1. Tile a transparent GIF as the background image.
  2. 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:-webkit-linear-gradient(hsla(0,0%,100%,0), hsla(0,0%,100%,0));

The first 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!