Change out the image using the SAME BASIC technique.
http://battletech.hopto.org/html_tutorials/eightcorners/corners2/template.html
Some minor differences, but the only thing major changed is the image… Which uses just one image:
http://battletech.hopto.org/html_tutorials/eightcorners/corners2/eightCorners.png
while being endless dynamic height and dynamic width up to half the image width. (so… 1280)… you need wider, make the image wider.
683 bytes of extra CSS, one 962 byte image, and four lines of markup at 214 bytes per box… beats the tar out of any ‘scripted’ solution in my book - especially since you can do MORE than just round the corners applying any image effect you can draw… as evidenced by using it for shadows in the primary code explaining it.
ESPECIALLY since it works all the way back to IE 5.x without resorting to anything browser specific like VML or half-assed browser specific nonsense like -moz and -webkit. (or as I call it, lands sake if you are going to make CSS3 support… MAKE CSS3 support) and works with scripting disabled - and given the number of people grabbing scriptblocks like noscript these days…
Mind you, my page also linked to a scripted version:
http://battletech.hopto.org/html_tutorials/borderimages_javascripted/template.html
That applies the wrapping div from the script using a class trigger. It too uses only one image per effect. The first three all using just this image: (515 bytes)
http://battletech.hopto.org/html_tutorials/borderimages_javascripted/images/unified.png
the last one using just this image: (1.3k)
http://battletech.hopto.org/html_tutorials/borderimages_javascripted/images/black_unified.gif
Hell of a lot more versatile than this border-radius nonsense… especially when even the crappy scripted version only uses 739 BYTES of javascript to apply it. (though I’ll admit most of that is from my sleazing out a shortcut by using innerhtml instead of the DISASTER the ‘by the specification’ approach with the DOM manipulation would be)
While you pointed at 17k of javascript to fake with VML something (CSS3 border-radius) that we aren’t even supposed to be using on production sites since the specification isn’t even out of draft? I don’t think so. After all, there’s a REASON in gecko and webkit they are still using the -moz and -webkit prefixes - since those TOO are supposed to mean “not ready for use on production sites”.