CSS problems with NC4: links won't work and pos:rel wrong offset

[luma]

Thought I could risk to post this in one message: The problems are related and if you want to check the code, you could just copy & paste it. Checked with Netscape Communicator 4.77 for Linux:

I would like to use a different background on links. This background should span the width of the column. background-color won't do it in Netscape 4, but using border:none and margin:0px should do the trick. There's only one problem: The links won't work any more (not clickable). Sample code:

<div style="position:absolut; left:0px; top:0px; width:200px;">
<a style="background-color:yellow; border:none; margin:0px" href="foo">short</a>
<a style="background-color:yellow; border:none; margin:0px" href="bar">very long link</a>
</div>

The next problem is even weirder: If using position:relative the link won't be clickable were it is displayed but instead if you point to the very left of the screen on that line, the link will be clickable. So there seems to be some offset problem.

<div style="position:relative; left:200px;"><a href="#foo">body link</a></div>

Using position:absolute would work. Is it just my NC or is this a known problem? And more important: Are there any work arounds that work in NC 4.7x?

PS: This is just sample code; the HTML and CSS code where I would like to use this does validate.

[tedster]

I recently ran into this bug on a new job where the client still needs NN4 support. It seems to happen in NN4 whenever there is a brder declaration for the anchor element.

My workaround involved two external stylesheets and wrapping every anchor tag in a <p> tag:

<p class="link1"><a href="page.html" class="link2">Text</a></p>

In the Netscape 4 stylesheet, I declare the border for p.link1. On the main stylesheet, I declare the border for a.link2

One of the issues is that NN4 will not display a background for the full block of a block element unless there is a non-zero border declared (well documented bug). But when you do that for an anchor element the link goes dead. Using dual stylesheets gets around this, and other visual anomalies as well.

[mivox]

I just ran into this problem the other day, and couldn't figure out a workaround. Currently, on that site, NN4 sees bold, regular, underlined links and everyone else sees CSS 'buttons' that change color with a:hover (an a second stylesheet delivered via @import).

Maybe I'll give your workaround a try, tedster... never even thought of it!

[tedster]

In the past I just served up a regular underlined link, as you mentioned mivox. But I spoke too quickly with this new client and guaranteed them that I could convert their main menu to all CSS: their menu is just square text boxes with borders, but their designer had done it with gifs and used a horrendous rollover javascript.

I promised them a css solution which would retain the look of their current menu, forgetting at the time that they required NN4 support. So, before I totally ate crow I was highly motivated to find a way to make this work. Hence, this workaround.

And by the way SHAME ON NETSCAPE for ever releasing a browser with a bug this bad. Breaking link functionality with a common bit of code is insane - even going back 5 years. They had to know the bug was there, and it's not cosmetic - it breaks the very heart of the web, the hyperlink.

[luma]

Thanks tedster. I really thought it could not be done. I solved the relative positioning problem by going absolute.

Cross-browser testing gets quite frustrating. Instead of focusing on proprietary gimmicks like colored scroll bars, browser manufactures should fix their rendering and other bugs.