I just noticed that if you hold the cursor over the very right side of the 'n' in S. Rolen's name on the 3rd base section of the page or in the 'y' in the J. Mabry's name in the same section you can get to the hyperlink. So the JS creating them is most certainly working correctly but the anchor tags must not be rendered correctly to encompass the whole text of the link.
The containing divs for each position (1B, 2B, ...) are overlapping. They're each 200px wide, absolutely positioned and have the same z-index, and the order in which the divs are created is significant (with respect to the reported issue). This sounds like the correct behavior according to CSS2. "Boxes with the same stack level in a stacking context are stacked bottom-to-top according to document tree order." see http://www.w3.org/TR/CSS2/visuren.html#stack-level
I see this point but further along at the bottom of section 9.9.1 in the W3C CSS2 doc, the notion of transparency is given. The following text seems to say that anything rendered in a box below should still be visible if nothing rendered in the box above actually overlaps, despite the fact that box borders do in fact overlap, i.e. hyperlinks should still be clickable if they are not covered by text/image/etc. from the above box. "The default behavior of a box is to allow boxes behind it to be visible through transparent areas in its content. In the example, each box transparently overlays the boxes below it. This behavior can be overridden by using one of the existing background properties." Given that nothing (text/links/images) actually overlap, only box borders, this to me is still indeed a bug.
"Visible" may be the key word. There's still a block there, but its background is transparent, permitting content behind is to be seen. (If the background was a solid color, the content behind it would be visually obscured as well, in which case the observed behavior would be completely expected.)
First off, let me just say, I'm not trying to be difficult, I'm trying to help. With that in mind... In the case that there is a background color, you are correct, the observed behavior of the hyperlink would be entirely correct. But in the case at hand, it is defined as transparent, and while you can SEE the text behind the box (correct functionality thus far), I would think that the mere visibility of the hyperlink would also allow its functinality. Clearly, any sort of interactive element (i.e. hyperlink, form widget, etc.) presented visually but without its functionality is going to confuse the average user. I'm a developer and HTML and JS literate and it still confused me why the links didn't work. I traced the problem as much as I could before I thought I should submit it as a bug. It was only after the block rendering cause was explained to me and I thought to turn on "Outline Block Level Elements" in the devleoper toolbar that my confusion passed. The average user will simply think, "this browser is broken, I guess its back to IE." Incidentally, I know several people who have thought this exactly same thing and done just that with their own experiences. Are you trying to win hearts and minds or is this whole browser merely an intelllectual exercize? Now don't get me wrong, I'm not trying to tout M$ as being better, I want Mozilla to supercede IE in every way which definitely on its way of doing. That is the only reason I bothered to submit and pursue this. So let me reiterate one point, IE renders the behavior the way I think it should be rendered and in the way that will not confuse Joe User so I'm not the only one who thinks this is the correct behavior. The W3C document linked for me in a previous comment, based on the section I quoted, does not clearly specify what should happen in this particular situation. Is there some method to resolve this by asking the W3C what the behavior should be? Perhaps coerce them to alter the doc to resolve the ambiguity at some point also? Thanks for listening.
Have a look at bug 102695. In particular, see the "simplified testcase." You may wish review a few of the bugs marked as duplicates of it as well. If that's indeed the same issue, please resolve this one with "Resolve bug, mark it as duplicate of bug # 102695." (Sorry for not locating that sooner.)
*** This bug has been marked as a duplicate of 102695 ***