I remember being impressed by Dragon Lab's Dragonfish Login Form Demo[1] when it first came out. They implement the effect by using a rather large background image and a mask image and move the background image around via Javascript.
I wanted to see how close I could get using CSS3 without any images.
I recommend using a Webkit browser [you can also see an alternate implementation using Firefox 4]
>> They implement the effect by using a rather large background image and a mask image and move the background image around via Javascript.
Scrolling the background image position with javascript can be really slow on even recent browsers, pushing the CPU when software rendering. Mobile Safari also shows image "seams" between mask images when zoomed out.
The button uses a combination of a border radius and and inset box shadow to achieve the top highlight, and for some reason Chrome doesn't seem to contain the box shadow within the border boundaries.
Usability problem: the animation attracts attention, distracts the eye. The moving glow, mixed with the small lettering, makes it hard to read quickly. When the animation finally stopped on my system, I was suddenly able to read the lettering easier.
That may be the one goal, but I think probably a bigger goal is to have animations that are handled by the browser itself (and not Flash), and can be written in lightweight code.
Honestly, this is the first I've heard of CSS3 animations as intending to be ultra-fast, but I admittedly haven't kept up on the HTML5/CSS3 discussions.
Maybe, or maybe not, but this is nowhere near as offensive as blink. This is fairly subtle, and if put to a greyscale series, it would be barely even noticeable except as some neat lighting effects.
"The logo is on fire," explains one surfer. "Why is the logo on fire?" she asks. "Uh," he stammers as the enthusiasm in his voice quickly dissipates, "it's a flaming logo."
Very nice. I recently tested out a few designs using large CSS3 shadows and it indeed slowed the browser way down when applied to a "FB Wall" number of page elements. Hopefully we don't have to wait for hardware to pick up the slack in implementation here.
The Webkit implementation uses 2 layers of: looped keyframes, color transitions, multi-colorstop gradient backgrounds (which are then animated via background-position animation). And all that sits under two larger inset rgba box-shadows. [+ the gradients and shadows on the inner form itself]
That said, I've actually been pretty pleased performance-wise, I expected worse.
Well, when you're doing a minimum of 256000 calculations per page element, you should expect some slowness (assuming a radius 256 filter requires a 512x512 kernel to process). A less naive implementation of blurring blurs horizontally then vertically, for a rough estimate of 2512w*h calculations, which could still be a lot for a lot of page elements.
I guess what I'm trying to say is this: don't expect to render a ton of large-radius shadows in realtime unless you're rendering with a modern game engine on a fast GPU.
The problem is that the intent of a user, when they see in a form, is to fill in that form. Adding a glowing background distracts them from their task, hence bad usability.
It's much like Google's homepage fade, which was originally added to draw attention to the search box (the primary focus of the page) and remove the distractions of the other links. The problem was that it fired almost all the time, and whenever there's an animation going on, your attention is drawn to the animation and away from whatever it is that you were doing. It ends up being counterproductive to animate parts of the page in order to highlight other, static parts of the page.
The POINT is the glow. That the glow works on a form is by happenstance, I'd suppose, as that was the original inspiration. Regardless, it could be a glow behind a blank div and I'd be equally impressed.
The nit that you're picking is akin to tasting someone's new gumbo recipe, and complaining that they didn't use the good china.
I think our interpretation of this is different. Your assertion is that she's trying to show people how to do something. My take is that she's showing people what she did.
Remember, about 25% of men are partially red-green color blind. So, a 'fire engine red' such as in the usual banner at HN such men can see, but lots of 'red' in mixtures of colors register as black. An emerald green can be seen, but in lots of mixtures the greens don't register. So, some light greens register as gray.
Mainly it makes him look color-blind, and used to people not designing accessible visual experiences.
The fact that he found the site difficult to read (like everyone else), he attributed to the most likely cause of such experiences in the past, i.e. his color-blindness, rather than the fact that the design is just really hard to read.
That the design is so difficult to read is done mainly to make the form pop out by contrast. It's a cool effect, but there's no way i'd deploy that for mass consumption. It's a piece of artwork in it's current state (albeit a really cool one).
Edit: Sorry, other people beat me to it. See other replies re:text colors.
However I agree about the contrast, I checked on my external dev monitor (vs. my super bright MBP screen) and the contrast could definitely use some work.
I'm "partial red-green" color blind. So, saturated, primary reds and greens I see as distinct. But if start to mix colores with some reds and greens, then I can see two colors as the same that other people see as distinct.
Partial red-green color blindness is very well understood. Nearly all colors that should be distinct still are but, yes, apparently I don't see fire engines and carrots just the same!
I wanted to see how close I could get using CSS3 without any images.
I recommend using a Webkit browser [you can also see an alternate implementation using Firefox 4]
[1]http://labs.dragoninteractive.com/panel/demo/