One may or may not like round corners. That, after all, is a matter of taste. But I somehow fail to see what’s wrong with using JavaScript to artificially round corners on some divs. Could you enlighten me?
Before sounding like this world’s most complete dodo, allow me to say upfront I am very aware of a number of issues: JavaScript rounding contraptions add weight to a page, will not work on all browsers and may even throw an error in some, could, if poorly implemented, botch your page’s layout and, finally, add a bunch of useless markup to a page… only to satisfy a rather pointless trend.
In the following entry, it is assumed you want rounded corners. For the record, I, FJ, like rounded and square corners about just as much and have no particular bias towards any. I do believe however a well-designed page can mix both and, in many cases, should mix both so as to provide proper visual information to its readers.
Yet, the more I read about the “proper” ways to implement them with CSS, the more I wonder. We all know the “proper” way is CSS3 and that it will have to wait — a long time. CSS2 provides us at best with vendor-specific extensions or unsupported declarations. Meanwhile, we all strive to deliver round corners that are vaguely compatible with Internet Explorer (because not everyone uses Safari) and don’t litter the code.
Most rounding corners use JavaScript libraries such as Behavior, allowing them to round divs based on a simple declaration of class — ie you can instruct the script, through a single line, to round all divs belonging to a certain class or within a certain container on the page. Of course, when the script kicks in, it will produce some extraneous markup but your actual raw document is clean. If you add that single line of JavaScript through a lone CGI script or SSI file across all of your site’s pages, one lone line of code takes care of all your rounding needs across dozen, hundreds or thousands of pages.
Sure, some browsers will understand zilch to the code but, hey, browsers have gotten very accustomed to ignoring JavaScript errors and, ironically, deal with them a lot better than CSS or XHTML markup. Also, provided the code is well written, errors will be limited to antique browsers that wouldn’t be supported by the pure-CSS methods anyway. As far as “bloat” goes, I agree reading a JavaScript file takes time but caching will alleviate that concern when a user browses an entire domain. And think of how many robots would load your extra CSS code while ignoring the JavaScript include…
In comparison, using background images and nested divs results in less actual markup at rendering time but, since you need to add three or four divs within each div you want to round, more style-related markup in every page. Worse, you cannot simply zap the single line within the JavaScript include file (however you make it work) to revert to a clean CSS2 layout, that you can then update with a CSS3 stylesheet when the time has come.
After all, I’m only FJ so I’m sure I’m missing something big. I know many of you are experts on web design matters. Would you care to enlighten me?
I feel that using javascript to round corners is really a choice. When I was designing nemu-nemu.com I had a heck of a time deciding which was the best and easiest way to round that didn't give me nightmares. After trying a ton of techniques I finally gave in and used NiftyCorners. I chose Nifty for a few reasons: it was easy to implement, it was easy to remove, it degraded nicely (if the browser didn't support it or didn't have javascript it would show your normal unrounded corners instead), and it didn't give me a headache trying to make them work.
I think Nifty is probably the easiest to implement and it's fairly lightweight compared to making graphic images of all corners in all different colors for each instance you want to round. I haven't had any complaints so far...
One caveat about using Javascript to generate rounded corners is the half-a-second it takes to do it. For most customers/users it is pretty acceptable and not a big deal at all, but it's often a big deal to designers and user interaction people.
I say use JS + CSS for everything that's not semanticly beneficial, but then again I'm a programmer-type.
If you do stick to using CSS with multiple nested DIV elements then the problems of layout only remains an issue if you are hand coding multiple pages. Using a template in some scripting language or other (if appropriate) will mean you only have to make the change once when it comes to it anyway.
KimonoStereo,
Thanks for taking the time to share your experience, it is most interesting!
FJ
Josh,
Yes, there indeed might be a slight delay while the script is being processed although I never uncovered one in my testing -- or any one longer than say, the time it takes to load that tiny brand logo in the upper left corner of the screen.
Of course, the temptation to go overboard with JavaScript and overload one's site is to be avoided and you are right in pointing out it is a potentially slippery slope.
FJ
Lee,
That is very true. In the case of a templating system or other CMS, either method, CSS or JavaScript, would only have to be used once. In this case, I guess CSS would have a light advantage. Of course, it all depends on whether the CSS is used to load images or not, which may again tip the balance.
I am somehow reluctant, as I said in previous blog posts, to use CMSs unless absolutely necessary but it is true many sites rely on them nowadays.
FJ
One could write an article titled, "What's Right With JavaScript?" but the hard part would be saying "not very much" in enough words to fill an article.
Like Flash intros, using Java$#!+ to do goofy things like rounded corners practically screams, "I don't have any worthwhile content on this site, so I'm going to give you funky effects -- that may or may not work on your browser -- as a poor substitute."
I know I'm the voice in the wilderness on this issue, but come on, folks. Fill your site with informative or entertaining content, and people won't care if you use the newest k3\/\/l web effects.
Je me doute que tu es d'origine francophone alors il me sera plus facile de m'expliquer dans ma langue:
Pour chaque tâche spécifique un outil spécifique. De même que l'on n'utilise pas un marteau pour visser, de même le JavaScript ne doit pas se mêler de style. À chacun son métier et les vaches seront bien gardées. :)
FARfetched,
First of all, thank you for taking the time to comment, I really do appreciate it.
You seem to imply "web effects" and valuable content are mutually exclusive. What about sites that bring on both? I entirely agree with you that an overload of effects will never replace actual content. However, what about effects that can help underline the content's meaning?
FJ
Arwen,
Merci de ton message et de tes commentaires!
LOL! En effet, un marteau n'est pas pratique pour visser... JavaScript est certainement plus approprié à la création de contenu dynamique qu'à la réalisation d'effets de style. Pourquoi cependant lui interdire de créer... des styles dynamiques, si j'ose dire? Je serais heureux de poursuivre cette discussion plus avant.
Merci encore,
FJ