Thursday, April 9th, 2009

jQuery Glow

Category: JavaScript, jQuery, Library


  1. $(document).ready(function() {
  2.       $('.white').addGlow({ textColor: 'white', haloColor: '#aaa', radius: 100 });
  3.       $('.blue').addGlow({ textColor: '#00f', haloColor: '#00f', radius: 100 });
  4.       $('.green').addGlow({ textColor: '#0f0', haloColor: '#0f0', radius: 100 });
  5.       $('.red').addGlow({ textColor: '#f00', haloColor: '#f00', radius: 100 });
  6.       $('*').bind('glow:started',;
  7.       $('*').bind('glow:canceled',;
  8. });

The code above, using jQuery Glow by Pat Nakajima, gives you a nice blur error on hover.

Make sure to mouse over the demo and check out the project.

Posted by Dion Almaer at 5:57 am

2.5 rating from 109 votes


Comments feed TrackBack URI

myspace there we come

Comment by V1 — April 9, 2009

has anyone else noticed how slow and jerky safari is when animating the shadow properties?

Comment by simon000666 — April 9, 2009

@simon000666 Nope, perfectly smooth here.

And all this sort of stuff is nice and all but it’s hardly job of js to just tween states. I’m not blaming those who develop this stuff, I do it, I use it, but this really should be part of CSS.

Comment by StuartJ — April 9, 2009

Why should it be part of CSS? It seems to me that CSS is perfectly correct in styling the two states at either end of a transition and leaving any other styling to javascript – there’s a clear demarcation between what CSS does – essentially just defining styles for two named states – and what javascript does – allowing further, programmatic control of arbitrary states other than those named, ie, during a transition.

Crossing clear lines of demarcation, IMHO, is the second greatest cause of all messy implementation (the first being sheer incompetence), and, as such, evil. I’m sure there are those out there who would argue that even CSS hover is crossing the line, or getting dangerously close. I wouldn’t agree, but I’d see where they were coming from.

Comment by jtresidder — April 9, 2009

thank god for jquery.

Comment by nataxia — April 9, 2009

He needs to add .stop() to keep things from going batshit crazy if you quickly hover in/out several links — taking the hover state to its proper end based on current style, instead of just going from a full start to a full end every hover.

Comment by MichaelThompson — April 9, 2009


I agree with jtresidder, this type of thing should not be in CSS. CSS should be for the “style” of the element and not its behavior. Consider how badly the different browsers have implemented the current “set in stone” CSS standards, there are several areas where they all disagree with each other. Adding in behaviors to CSS is just asking for trouble.

This glowy thingy is a prime example. The demo only worked as advertised on Safari and Chrome. But each one displayed the glow differently so that in Safari it looked good and in Chrome it looked like crap. Both have the same text-shadow property available but each renders it differently.

Comment by travisalmand — April 9, 2009

To me, the behavioural aspects of CSS start and end with :hover. This is a trigger which, IMHO, should’ve been left to js. having an animated glow effect to highlight a button, for example, is well within the rulings for CSS.

I shouldn’t need to change the js every time I change the stylesheet for a page. The web is not a static page anymore, If I want a button to glow or merely to be rounded this is surely a style that I would apply to it and not an interaction behaviour.

I understand the concerns regarding this, I do, but I do think that having a library of styles that i can apply to elements without relying on js is a good thing.

As for cross browser – well, that’s something else altogether.

Comment by StuartJ — April 9, 2009


If you just want a glow on an element then that’s one thing. If you want that glow to transition over time to appear or grow then I wouldn’t agree.

But I’m not sure if I understand. You seem to be saying you don’t like :hover but you want a hover glow effect?

Making a button rounded is not an interaction, that is a style. If you move the cursor over an element and you expect that element to change its appearance due to that action then that is an interaction behavior. True that the CSS can control the appearance of both states of that interaction but it is still an interaction.

I’d rather the CSS standards be updated to offer more options in terms of styling elements, not controlling their behaviors.

Comment by travisalmand — April 9, 2009

hrm, what’s next, “hello world”? and one that breaks at that…

Comment by christoff — April 9, 2009


has anyone else noticed how slow and jerky safari is when animating the shadow properties?

I just tried it in Safari 4 Beta and was totally impressed by the smoothness of its animations, considering I’ve noticed big performance issues with shadows in Safari. That’s what I came here to comment on, in fact. Amazingly fast and smooth.

@everyone: I agree with StuartJ, basic style-to-style animations are firmly in the realm of style. Transition is not a “behavior”, it’s an element of style. The arguments *against* CSS animations, taken to their logical conclusions, would necessarily lead to the conclusion that hover and active should be removed from the spec. Hover and active states are *behaviors* by the same definition. Meanwhile, we’ve had those states for a while, and have always had one-frame animations with them. There is no reason not to allow additional frames in those animations.

Comment by eyelidlessness — April 9, 2009


What I’m saying is that a cycling transition or basic animation (see iPhone icon wobbling on home screen) is fine for CSS, these are styles you can build in a stylesheet and apply them to an element at will. That’s great. The issue I have with :hover is that it’s an issue to the browser to change something on screen, that is a js job. So, if I wanted a glow effect as in the example I would like a CSS rule for the glow and transition all ready to go to be triggered with js on a rollover. It’s just my opinion that if you’re styling an element you shouldn’t have to use js to do it, only to trigger it on a change.

I actually don’t see how having a simple animation attached to an element is a behaviour. Yes, the webkit transition and animation implementation will allow all sorts of exploits that aren’t suited to CSS, but I don’t think it’s the job of the vendor to police bad design decisions.

In regards to my example about a button, I was specifically thinking about the OSX breathing blue gel button, usually the OK button. That to me is a style, it’s not an animation, it’s not a behaviour, it’s a style that just isn’t static.

Comment by StuartJ — April 9, 2009

Hovering over cause scroll bar to show and then hide afterward, making the whole page shift.

Comment by hilo — April 9, 2009

very basic and not well done.. I guess it’s for the beginners.

Comment by leptons — April 9, 2009


Thanks for the constructive comments. I’d love to hear about what I could be doing better here.

As for the CSS discussion, I’d agree with the points being made on both sides. I tend to prototype things in JS before I jump into the CSS implementation. It’s like drawing on a napkin for me. I’d love to see an implementation of this effect in CSS though.

Comment by nakajima — April 10, 2009

Ajaxian always have the best reminder, that we have Friday!

Comment by digitarald — May 8, 2009

Doesn’t work for me in Firefox 3.5.5. Did get it to work in Safari. I just finished up with adding support for text shadow animation to the UIZE JavaScript Framework. I think you’ll find something interesting to look at here…
UIZE provides powerful ways to control the animation of the smallest components of CSS style property animations, allowing some mind-blowing effects to be produced.

Comment by uize — December 4, 2009

Leave a comment

You must be logged in to post a comment.