By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,767 Members | 1,255 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,767 IT Pros & Developers. It's quick & easy.

Figured it out..

P: n/a
I'm not sure if it was acting according to the standards or if it was
just a bug I triggered in IE 5.2 for the Mac. But the issue with it
rendering weird was due to IE 5.2 (Mac) was that the search input box
was acting like default block level element that fills the width of
its container. Then the container where the search box was located was
making the default height of the container to be several PX tall thus
pushing all relatively positioned elements bellow it to way at the
bottom of the screen.

So my work around was to set a height to the container, and a width to
the input search box.

so this means one of two things:

01. I triggered an IE 5.2 (mac) bug
02. All the other browser I tested in have not followed the defacto
standards when it comes to the box model, I tested in Mozilla (1.0 &
1.4), Netscape (6.0, 7.0 & 7.1), Firefox .8 (Mac and Pc), Safari,
Opera (4,5,6 & 7.5), and IE (5.0, 5.5 & 6.0). All of the above
mentioned browsers render the page correct (except for Opera 4-6 which
doesn't like the floating in the bottom and top navigation, but only
the bottom navigation really blows up).

The Master

P.S. oh almost forgot IE 5.2 also does something weird with the first
link in the top nav. It clips the first 4 letters as though the Image
is higher in the z-index. Yet doesn't clip the border set on the UL,
which contains the text the image is clipping. Again this only happens
in IE 5.2 (mac).
Jul 20 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.