I have a long text and I'd like to offer the user a reading help: The current line should be highlighted. To make it easier, I'll just use the Y coordinate of the mouse (this way, the mouse pointer isn't going to get in the way). I have a big DIV with the id content which fills the whole width and a small DIV with the class content for the text (see here for an example).

I'm using jQuery 1.4. How can I highlight the line of text that is closest to the current mouse position?

3 Answers
3

Not sure if jQuery will help you out much here, but you could take a look at the element.getClientRects method, documented on MSDN and MDC. More specifically, this example at MSDN is sort of similar to what you want to achieve, highlighting lines using a cleverly z-indexed div element that goes behind the text at the co-ordinates returned by getClientRects().

You should be able to achieve the same thing by looping through the TextRectangle objects returned in the document's onmousemove and checking to see if the y value of the mouse cursor is > the top and < the bottom of each rectangle and moving the cleverly z-indexed div to the same position/height.

UPDATED - working in Chrome, IE6/7/8, Firefox, Opera, Safari. The initial problems I had in the other browsers were related to the DIV needing to be display: inline.UPDATED AGAIN - I had to refer to this answer for some newer questions, so I took the time to update it to recalc the lines on window resize. It looks like others have been playing around too, it's now on revision 15.

I don't see how you could feasibly do this without explicitly-wrapped text (i.e., newlines or <br> elements).

To the best of my knowledge, there's no way for the DOM to discover where a specific piece of text has wrapped, character-wise nor pixel-wise - including what I know of the Range API - not to mention the dynamic nature text can assume, such as with the text-zooming feature of browsers.

But if you could somehow manage to generate/inject explicit line-endings, then I think I have a solution for you.

EDIT

Thanks to the awesome information in Pekka's answer, I've cobbled together a functional prototype, but it has a significant caveat - works with plain-text content only. Any HTML present the body of the element will be stripped.

The best approach that comes to mind is splitting each line into a <span> or <div> element that has a :hover CSS class with the "highlight" setting set:

span.line:hover { background-color: lightblue; }

That would be the least expensive solution, as the browser is going to take care of all the highlighting itself. If you want fancy effects, you can still achieve that by adding mouseover and mouseout events to every line.

The tough part, of course, is splitting the content into lines at the browser's line break. You need to do that dynamically so the lines actually reflect the positions at which the browser breaks the text.

Maybe the accepted answer to this question is a step into the right direction:

It goes through the entire element (actually, a clone of the element) inserting a element within each word. The span's top-offset is cached - when this offset changes we can assume we're on a new line.

Nice find, and a good creative approach in the other question to discovery a line in arbitrary text.
–
Peter BaileyMar 16 '10 at 17:25

I agree, it's a creative approach, but wouldn't it be rather slow if there were, say, 1000 words? You would expect the DOM insertion to be very costly in this sort of situation.
–
Andy EMar 16 '10 at 17:42

@Andy The big plus of this approach in my eyes is that it's JavaScript heavy on page load, but not while the actual highlighting is done, while a solution doing real-time highlighting would be doing calculations the whole time. Also I think the DOM insertion would be justifiable even on a slower machine - but that will depend on the method used, of course. One would have to actually put this together and do some profiling to be sure.
–
Pekka 웃Mar 16 '10 at 17:49

See my answer for an example using getClientRects() - it's much cleaner and I don't think the calculations are costly because the collection returned contains objects with static properties only.
–
Andy EMar 16 '10 at 19:06