Safari and Transparent Borders

I had noticed this little bug on my own site. In the footer, there's a 5px border with the colour set using rgba. In Safari, it's as if the semi-transparent borders overlap each other in the corners and the values are compounded. This creates little squares in the corner of my squares.

Safari rendering compounded values in the corners

Not quite what you'd expect. Firefox and Opera (10.5; I didn't test in 10.10) render this as you'd expect, with a consistent colour surrounding the block.

In testing some other border handling, I noticed that the overlapping only seemed to happen when the border colour was the same on all sides. If the border colour is the same but the border width is different, you'd still get the overlapping values in the corner.

Now, how far apart do the colour values need to be before it reverts to a different way of rendering the borders: generally 3/1000th of a difference.

With the following CSS, the borders render closer to expected in Safari:

border-color:rgba(0,0,0,.201) rgba(0,0,0,.204);

Safari rendering better values in the corners

You can still notice a slight line at each edge as I suspect some anti-aliasing is at play. This is consistent between both Safari and Chrome, since they're both based on Webkit.

Published January 23, 2010
Categorized as HTML and CSS
Short URL:


25 Comments · RSS feed
Mark Story said on January 23, 2010

I wonder if you would have the same issues with a transparent png and a border-image. It seems that the different colours triggers a different border corner rendering behaviour. Thanks for sharing this :)

David Calhoun said on January 23, 2010

There also seems to doubling of the corners on rectangles in all implementation of the <canvas> element, from what I've seen. Seems to be a common issue.

Simon Sigurdhsson said on January 23, 2010

That's interesting... has this been reported to the Webkit team? I can't find anything in their Trac.

Travis Isaacs said on January 23, 2010

Curious as to how it would look with border-radius...

Jonathan Snook said on January 23, 2010

@Mark Story: that'd be an interesting thing to try. Alas, I'm too lazy now to try. :)

@Simon: I hadn't checked, actually. I should probably do that.

@Travis: Once a border-radius is applied, it's no longer an issue. However, you now have rounded corners! :)

Anthony Short said on January 23, 2010

What about applying a -webkit-border-radius:0;? That might change the rendering of the borders but still keep them square. Just a guess.

Jonathan Snook said on January 23, 2010

@Anthony Short: And that guess would be incorrect. :) I tried and sadly, a border-radius of 0 does nothing.

Cesar said on January 23, 2010

Hmmm...very interesting find, I'll have a look at it and see if I find something.

Cesar said on January 23, 2010

Yep, I got it, time for a new approach:

#flickrfaves img {

But a very weird error indeed...

Johan said on January 24, 2010

Can you not use opacity on solid borders instead and set only the border styles on a wrapper SPAN?

Johan said on January 24, 2010

Also Google chrome has the same issue, uses the same render engine, not so?

Jylan Wynne said on January 24, 2010

I’ve noticed this behaviour myself - never had the inclination to investigate further though. Thanks for the simple solution!

Chris Coyier said on January 24, 2010

I noticed the same thing on a box I created the other day. I'd say it's definitely a bug, as I can't imagine it's the desired affect in most circumstances (although I kind of liked it and kept it in my case). Interesting that the 3/1000th difference is imperceptible (at least to me), which should make for a good short term workaround.

pablo Boerr said on January 24, 2010

I recently came across the same thing, will definitely try this work around, have you noticed a difference in the other browsers after applying it?

Thanks for sharing

Jonathan Snook said on January 24, 2010

@Johan: it doesn't matter where you apply the border, the problem will still occur. And yes, as mentioned in the last sentence of the article, the same thing applies to Chrome.

@Pablo Boerr: all other browsers apply the border as expected, with no artifacts at the corner.

pablo Boerr said on January 24, 2010

Thanks jonathan.

Derek Anderson said on January 25, 2010

If your border-size is larger than your border-radius you will run into trouble in Safari :
<img src="" width="302" height="232" alt="Transparent border issues in Webkit" />

this is the CSS used to produce the weird inverted corners

border:50px solid rgba(0,0,0,.200);

I wonder what's going on there...

Dutch said on January 25, 2010

Yes this does seem a little off, if you were to build it out of 4 borders, then yes it would be right. (that's what it is rendering afaik).

If it were to be 1 border it should render it as a whole, not as 4 separate edges).

Pat said on January 25, 2010

I honestly thought that was part of the design aesthetic you had created for the footer. Thanks for highlighting the bug, though!

Tomaz Zaman said on January 26, 2010

It's a bit of a tradeoff but why don't you apply solid border color instead, small squares would go away and everybody would be satisfied :) The difference will be the same as with your technique of different colors.

Eric Guess said on January 28, 2010

is it bad that i kinda like the how webkit is rendering this? i'd call it progressive enhancement, have a shot of tequila and call it a day!

alex said on January 29, 2010

Thanks Snook,
this posting for transparent png and a border-image has given clear concept and thanks again for sharing code.

Norman said on February 04, 2010

Just found that bug today, while writing an article about RGBa colors.. pretty weird and something the Webkit should fix as soon as possible.

Andy L said on March 02, 2010

Jonathan, please submit this as a bug:

Thank you.

clark mercer said on February 14, 2011

thanks DEREK ANDERSON. you were right on -- solved my problem!

Sorry, comments are closed for this post. If you have any further questions or comments, feel free to send them to me directly.