The code hasn’t been added to your live page yet so please add it and we can test from there. I’m sure you will find it will fix the issue once added because I previously copied your whole site locally to test. If not then I need to see that the code is in place before testing again to see what went wrong. You seem to have added #masthead{display:block} but that’s not what I said you should add.
I noticed (it didn’t cross my mind to do it before) that in compatibility view it displays ok; problem is most users of the site are not familiar with that (go figure I am a bit more into it and did forget to check it).
Compatibility mode is a mess and should be avoided at all times as 9 times out of ten it makes things worse. It may appear to fix the issue due to legacy handing of inline elements which in ie5 which could have dimensions applied (as they were more akin to inline-block). This is triggered by quirks mode which is basically what happens in compatibility mode but with differences.
Would you care to explain it a bit more please?
In html5 you can now do this:
<a href="#">
<div>block content</div>
</a>
However, browsers still hate it and will cause rendering problems unless you set the anchors to display:block. I have answered to or three questions recently in the forums where this has caused issues.
Also I hate to see things like this:
<div>
Some text
<p>Some more text</p>
</div>
The 'some text" runs into a block element and so the browser must construct an anonymous block box to hold this stray text. In older versions of IE these structures would often cause rendering problems in complicated layouts but semantically it is bad also as the initial text should also be in a suitable container to add semantic meaning to the snippet.
<div>
<p>Some text</p>
<p>Some more text</p>
</div>
It would also be incorrect (semantically speaking) to have this:
<div>
<span>Some text</span>
<p>Some more text</p>
</div>
Although it is valid it makes no sense semantically as to why one section of text is a paragraph and another similar one is not.
In your case the image was an inline element and then you followed it immediately with a float (a block display). When floats follow inline elements the inline element should be moved out of the way so that the float can move to the right on the same line (assuming there is room). This combined with the negative top margin was confusing some versions of IE. Without the negative top margin the float stays underneath and visible but once the full negative top margin was added the element disappeared. Setting the image to display:block forces the float to start under the image and not collapse its margins. At least that was my best guess as to what it was doing.