I stumbled across a very cool effect caused by CSS and the ability of a browser (in this case, Firefox) to do text layout in realtime. The original link was http://valleywag.com/tech/numa-numa/ but it has come & gone out of 404-land for a while now. I have attempted, with mixed success, to reproduce in the continuation of the post the weird behavior as I first saw it. Here's what it looked like on Valleywag when this was first posted.
The top pic shows some text on the Valleywag site. The words Numa Numa are marked up as a link (though they aren’t styled any differently to let you know that in advance).
In the second pic my mouse is hovering over the first Numa. Notice that the CSS calls for active links (i.e., when hovered over) to go bold and to change color and background color. Activating this link has kicked the second Numa to the next line, since in its bold form it no longer fits on the line where it was.
What do you suppose happens when I hover the mouse over the second Numa? Twenty points for Gryffendor if you said “flicker!” About 15x/sec. as best I can estimate, on a 2.16 GHz Core Duo. Hitting that word with the mouse activates a CSS change to bold, the word no longer fits, it whips to the next line as the paragraph is re-layed-out, and… the mouse hovers over empty space! The link is no longer active and the CSS causes it to go back to its ordinary, un-bold state. Now it fits on the line above and the paragraph is re-layed-out, and… the mouse hovers over the link again!
Lather, rinse, repeat until the epileptic fit commences.
[Note added 2008-05-31] Since the Valleywag link above went 404 long ago, I have attempted to reproduce the test case below. Once upon a time it behaved as expected in Safari (Mac) and IE6 / IE7 (Windows) — that is, the a:hover style is applied, the second Numa moves to the next line, and there's an end of it. The mouse is stationery in the space where the first Numa was, but the link is still active. [Note added 2009-07-22] As of version 3.5, Firefox no longer flickers. One reason for this seems to be that the bold weight of the font takes up no more horizontal space than the regular weight. Also, it has become more difficult (read: impossible) to format the example below so that it renders identically in disparate browsers.
This all put me in mind of a test case I once set up, back in ancient history — we’re talkin’ 1981 or so — when I was working at DEC on the code for Digital Standard Runoff, or DSR. My group had modified the venerable Runoff so that it could do table-of-contents, indexing, tables, and cross references. It was the latter I was proudest of: no text system then in existence could do crossrefs automatically. (And none could do tables as elegantly, or indexes as professionally.) As part of the test suite I set up for DSR, I had it process a document of over 90 pages in which the page numbering had been styled to appear as Roman numerals. At the very bottom of page 89, I placed a crossref to an anchor embedded in the immediately following word, which ordinarily was the first word on page 90. The text of the crossref looked something like “See page <crossref-anchor>”. The way crossrefs were processed was in an iterative batch run over the marked-up input file. As DSR layed out page 89, the cross-ref expanded to “See page XC” — i.e., “90” in Roman — and this left room on page 89 for one more word: the word containing the anchor. On the next iterative pass the crossref expanded to “See page LXXXVIII” and the following word, containing the anchor, was kicked back to page 90.
Lather, rinse, repeat.
I had coded for the infinite loop case and the software picked one and moved on after (I think it was) three times over the same ground.