a little back story

A few months ago, the IE Blog showcased some IE9 goodness and made a call to action for better border-radius implementations. They rightfully shown how they are getting it right this time, and how most other browsers out there are broken, with Safari/Chrome (Webkit) being the worst still at the time of writing this article. But not everything in their implementation is correct, IE9 pre 3 still exhibits the same issue as the other browsers that I'm presenting today.

the big bug theory

So what's the issue with border-radius? simple answer: the background color bleeds behind the radius when you also have a border in the same element.
Let's first use a real world example of a live site that paradoxically exposes the bug: HTML5 Rocks Playground

Chrome 5.0.375.99 on the left, Firefox 3.6.6 on the right, Windows 7 with ATI X300

See the blue garbage on the rounded corner? that's what most browsers do.

Now, to rule out a possible specific software/hardware combination, I went thru several test machines and browsers to see if the bug was repeatable:

reproducing the bug

So how hard is to reproduce the bug? sadly, not at all. Here's the base recipe for disaster:

1
2
3

border: 3px solid #999;
background-color: #f00;
border-radius: 20px;

zooming-in the issue:

Firefox 3.6.6

Chrome 5

Opera 10.60

IE9 pre 3

given the previous example and screenshots, you might have noticed the other issue: Firefox is not actually bug-free. It has a slight issue blending the element background with the border. it's not as bad as the bleeding issue, but it's still annoying. Also from the previous set and this one, we notice how the IE9 and Opera 10.60 implementations are an order of magnitude better than what Webkit achieves.

finding a work-around

As you might have guessed, the only reliable work-around to date is nesting rounded elements when you need a distinctly colored border. Using padding on the outer box equal to the border-width required does the trick and works across all browsers:

Of course it's not all fun and games, you need to specify a different border-radius for the inner box as they both have different sizes. In this case, the outer box has 25px while the inner one has 23px.

Can we stop with the pain already? How many years have passed since the first border-radius implementation and they are still getting it wrong?
this is how I feel about the current state of border-radius:

Can every browser get it right before boring us once again with their endless speech on how shiny and compliant they are? It's not frelling rocket science.

Enter the MooTools

While the original version used jQuery (1.2.6 at that time) and lots of people like it, we (mootoolers) have a different approach to code specially emphasizing on OOP techniques and readability. Part of the issue might not be jQuery per-se and be Dave's code that was a little obfuscated, but it anyways has a lot of room for improvement.
This article will just describe differences between the MooTools implementation and the Dave's jQuery one, so unless stated otherwise, everything from the ALA article applies here.

enter the Sprites2 class

Part of the requirements I imposed myself when porting to MooTools was that it had to be easier to use than the jQuery version, and that it should give a certain degree of flexibility to extend the possible transition effects.
End result is a class intuitively named Sprites2, where you gracefully pass named parameters:

1

new Sprites2({mode: 'fade', item_selector: 'ul.nav a', duration: 250});

changes to original code and idea

Apart from moving the code to a class, a change to note is the removal of the :active state from the CSS and the setActive parameter in the JS code. This was mostly a personal preference as the :active pseudo-class created a few issues when holding the mouse on the element and releasing outside of it. Other notable changes in the CSS are the simplification of the implementation/adaptation process by using a simpler approach on the styles (for example, using height:100%; where applicable instead of redefining height:48px; 5 times in the CSS).

MooTools also has a free "upgrade" built-in: animations have an internal state so that if you roll out from the element and enter it again, the transition will continue to run smoothly. In contrast, jQuery version (may be by code design, maybe because of a library limitation) flickers madly when you roll over and out of the element repeatedly with an interval less than the effect duration.

Also to note, and as mentioned, the Sprites2 class can be easily extended outside of the sprites2.js file with just a few lines of code to create for example a horizontal slide effect:

1
2
3
4
5
6
7
8
9
10

Sprites2.implement({
  effects: {
    slide_x: function(fx_element) {
      fx_element.store('width', fx_element.getSize().x).setStyles({'width': 0});
 
      this.show_fn = function(fx_element) { fx_element.tween('width', fx_element.retrieve('width')); };
      this.hide_fn = function(fx_element) { fx_element.tween('width', 0); };
    }
  }
});

and you can start using it right away with new Sprites2({mode: 'slide_x'});. This obviously works any way you want, as you can manually add or remove the effects directly in the source file.

download, full demo and requirements

The example here is running on a standard google hosted version of mootools 1.2.1. For those of you that use custom builds, just be sure to add FX.Tween and FX.Morph to your standard array of includes (morph is only used by the "animate" effect, so if you don't use that one you can exclude it.)

View full online demo

Download Sprites2 for MooTools [zip].

new! – by popular demand (not really), I have just set-up a git repo so you can fork the latest source: http://github.com/gonchuki/sprites2-moo

License: Creative Commons Attribution-Share Alike 3.0
disclaimer: original code did not contain any license whatsoever (like all ALA code), so I assumed a CC share-alike license applies perfectly in this case.
]]> http://blog.gonchuki.com/archives/css-sprites2-its-mootools-time/feed/ 24