I just got bitten by an issue with the :hover CSS element not working in a page where I'd been trying to highlight grid rows. It's really easy to create highlighted rows on hovering as in the following CSS:
#gdViewData tbody tr:hover
{
background: orange url(images/lightorangegradient.png);
cursor: pointer;
}
which makes for an easy way to create selectable rows. Hook up a click handler with jQuery (or an old style onclick attribute on the row) and you have a super easy picklist that looks nice and interactive:
The jQuery selection .click() handler hookup then simply navigates:
$("#gdViewData tbody tr").click( function() {
var id = $(this).attr("id").replace("gdViewData_","");
window.location = "AppletViewer.aspx?id=" + id;
});
:hover is breaky in IE
But... unfortunately when I tried this today it didn't work - at least not in IE 7. All other browsers - including IE 6 seem to properly render the row highlight but IE 7 doesn't.
As it turns out this was an error on my part as I somehow managed to wipe out my DOCTYPE document header in the HTML. When the doctype header is not present IE renders in quirks mode which doesn't properly support hover on elements other than anchor (<a>) tags.
There's more info on the issue along with a few links to documentation here and this is a known issue. IE doesn't render :hover tags properly unless it is in strict mode. This appears true - oddly enough - even for IE 8 which also didn't render the hover behavior with the document type header, which is surprising given that IE 8 supposed is running in strict mode to begin with.
In any case for ASP.NET developers this shouldn't be an issue since it creates the XHTML header by default for new pages. In my case I just accidentally wiped out the doctype header and didn't realize it until I found the solution mentioned above. Actually this accounts for a host of other problems I also had on the same page which now thankfully renders more consistently across browsers.
Just to be complete here's the transitional XHTML header I'm using that DOES show the hover behavior in IE 7a and 8:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
More Problems with Large Tables
In this particular application I'm working on we're generating some rather large lists in some cases. Basically the list we display is a dynamic user defined query and the result data is displayed as a table and scrolled rather than using paging. We still page, but only for very large page sizes (500-1000 pages actually) - otherwise the list is just rendered. Download performance (it's an intranet app with data coming off local servers) and rendering in the browser produces fairly quick responses.
However in IE 7 the hover behavior on large lists starts stuttering badly. If I have 50 rows or so the hover behavior tends to be fine, with hovering working quickly and smoothly. However with large lists that have more than a hundred items the hover highlight becomes horribly delayed. With 500 rows the (or smaller lists with wider column counts) the hover highlight shows up something like 2 seconds after actually hovering over an element which makes for an interesting selection experience <g>.
Other browsers show no problems even with the larger lists - again it's only in IE that that there's a problem. It's almost as if IE is literally attaching mouseenter and mouseout events to each row to provide the hover behavior and choking on the massive amounts of event handlers that are in place. In fact, earlier when I tried to figure a way around the IE non-hover problem I actually created a jQuery.hover() method hookup to simulate just that scenario and I saw EXACTLY the same behavior when doing so across all browsers. Same lag and horrible performance. <shrug>
That sucks. As a result we have to rethink the page size we can possibly display in our scrolling layouts. Unfortunately in this app seeing large results and browsing through them is a common scenario and we're already doing pre-filtering with filter fields, so there's not a lot more that can be done to reduce the result size.
But on the upside, since this is an internal app we're pushing for FireFox as the recommended platform - "Use IE at your own discomfort." <g>
Other Posts you might also like