My webpage is suffering from two IE6 rendering bugs. Each of them have workarounds, but unfortunately said workarounds are incompatible with each other.
Here's a minimized test case. The behavior in Firefox/Safari is the desired/correct one. IE7 is unknown, since I don't have access to it right now.
First bug: #content has overflow: auto and contains a relatively-positioned div. IE6 incorrectly gives the relatively-positioned div a 'fixed' appearance. Workaround: Set position: relative on #content.
Second bug: The page sometimes shows a modal popup. The z-index on the popup and background are set really high to stop anything behind them from being interacted with. This works fine until I set position:relative on #content, which makes IE6 treat the z-index property completely wrong.
How can I make these bugs play nicely with each other? (Note: Remotely formatting the hard drives of users still running IE6 is not an option, much to my dismay.)
Edit: Here's a second test case that shows what happens when I apply position: relative to content. The first bug ('fixed' appearance of #content-header) is solved, but it causes the z-index bug to kick in and mess up the modal background.
There are a myriad of implementation as to how to avoid the massive issues with ie6 (and below) conformity. The only one that has actually worked for me (to a great extent even) is Dean Edward's solution.
Try to insert the following line in your main header:
<!--[if lt IE 8]><script src="http://ie7-js.googlecode.com/svn/version/2.0(beta)/IE7.js" type="text/javascript"></script><![endif]-->
-- and see how it goes from there (and what you still need to handle, since it probably won't fix everything).
The script size is a mere 30kb, and will only be loaded in ie6 and ie7.
The google code url is (obviously) http://code.google.com/p/ie7-js/
Implement something like we've done at Ra-Ajax.org (hint, visit the site with IE ;)
Seriously, even prototype.js and 37signals have STOPPED supporting IE6 now, I think it's time to move on...
I don't think using a library is too bad of a penalty to minimize my time working around ridiculous IE bugs.
We ended up using the bgiframe jquery plugin (http://plugins.jquery.com/project/bgiframe). It implements the iframe "shield" technique in a library. I figure that making IE6 users have to have a bit more of a library download penalty (which isn't really all that much) so that I don't have to go crazy about IE6 bleedthru is worth it.
P.S. I think the web developers of the world should start a class action lawsuit to force Microsoft ether to offer the equivilant of firebug for IE6 and IE7, make sure all IE6 and IE7 instances are upgraded to standards, or remove all versions of IE6 and IE7 from all computers on the Internet, or bail-out all web developers with a payment of $1M each for their pain and suffering!
While it may be the wrong solution, and probably way overkill, jQuery can do modal popups similar to this and works on IE6. I'll probably get downvoted for such a simple answer, but it is still worth considering, or at least looking at, other solutions before reinventing the wheel.
Related
I've built a webpage, everything looks great in IE7 and upwards but in IE6 it's looks bad.
I have a whole div which has a background image that's not even showing up.
Why could this be? Are there common things that tend to not work that could be in my CSS? I don't normally support IE6 so don't usually have to figure these things out, but my client has specified that they want to work in IE6.
Here's the site, yep - quite a nice site in modern browsers! http://www.replyonline.co.uk/ie6sucks/index.html - feel free to look through the code (there's a IE6 specific stylesheet at view-source:http://www.replyonline.co.uk/ie6sucks/css/anythingslider-ie.css where I've solved some of the existing issues.
Thanks
I don't have an IE6 install with me here, but here are a few hints:
It's most likely a positioning ('hasLayout') issue. Try setting zoom: 1 on the missing DIV or its parent(s). The same goes for position: relative or a combination of both.
Also, check some of the content-hiding bugs on PIE: http://www.positioniseverything.net/explorer.html
You can use the Internet Explorer developer toolbar to try some of this out: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=95e06cbe-4940-4218-b75d-b8856fced535. Keep in mind though that some bugs will only appear or get fixed on a full page reload, and not while fiddling with the CSS in the developer toolbar.
I also use XRAY ( http://www.westciv.com/xray ) a lot to see how my elements behave.
For more info on 'having layout', see http://www.satzansatz.de/cssd/onhavinglayout.html.
It's tricky to debug since I don't have a working copy of ie6 on my machine, only ietester but there are known issues with ie6 where it doesn't calculate sizes properly in order to display background images properly.
The answer generally is to trigger hasLayout on the element and the easiest way to do this is using position:relative. I'd give that a go before anything else.
I would also recommend having a look at the html5boilerplate stylesheet to see if there is anything there that you can make use of. The reset/reassign css in there is simply brilliant and irons out a lot of css issues.
Best of luck!
1 - Make sure your site validates: W3C Validator Currently yours doesn't ( 146 Errors, 16 warning ).
2 - There's an annoying bug in IE to do with margin/padding, if you have any to the left or right of an element, you may need to do display: inline or inline-block;
I've found little things like this can help.
Looking at the W3C results, it looks like you may have too many closing div tags
Webkit is an awful renderer in my opinion. As a web designer/developer, I take into account how my design looks at every magnification. Webkit handles this extremely poorly. Margins, padding, and borders all get rendered extremely poorly across various magnifications and there is no CSS you can use that is "cross-zoom" compliant in WebKit. Zoom in and out of any webpage in IE, Firefox, Opera and it is consistent. Take a look at this site, for instance:
http://development.mminc.co/davidphotos/
Try using the carousel at the bottom at different magnifications in IE or Firefox. Works fine, right? Now try the same thing in Chrome or Safari. BOOM! A developer's nightmare! Please, if anyone knows of any tricks of the trade to get Webkit to behave with something that even Trident is able to successfully do I'd like to hear it. I've heard of a jQuery zoom plugin, but that is sort of a last resort. I've looked everywhere for the issue but no one even mentions Webkit zoom issues. It's like it's taboo or something. Personally I think it's one of the biggest blunders of the modern browser era, especially when such a (otherwise) great browser like Chrome is giving me more trouble with presentation issues than IE7.
EDIT: I feel I should be more general and use an example where it is obvious only HTML and CSS are implemented.
http://www.gamespot.com/
Webkit forces a line-break with the top menu w/ zoom tests, but other browsers don't. It is a major issue with the engine and if there are any concrete solutions I'd like to hear them. If there isn't then I think this issue should be addressed and resolved immediately; it is an eyesore to users and a nightmare for developers. The fact that it isn't addressed anywhere on the net is troublesome.
This isn't answering how to fix WebKit zoom issues in general, but it should help with your specific problem.
You're using jCarousel.
Even the simple demo shows the same problems you describe.
So, that plugin is simply broken when it comes to zooming with WebKit browsers.
You could either ask the author of the plugin for advice, or find a different carousel plugin.
For instance, this one doesn't seem to have any problems when you zoom in using a WebKit browser:
http://www.thomaslanciaux.pro/jquery/jquery_carousel.htm (look at the "dispItems" demo)
I've discover so far that:
stating the width in some elements fix issues in IE.
and of course using a CSS reset
Do you know any others?
Learn about hasLayout
Inline block behavior can be achieved on IE7 by turning on hasLayout, then setting display to inline. This has turned out to be quite useful to me.
Make sure your doctype is present and correct. This alone can save hours of pain.
Use conditional comments anytime you need to hack something especially for IE. PLEASE don't fall into the amateur's habit of adding star/underscore junk in your main stylesheet.
I'd say that manually setting width would more often than not break things in IE, as a lot of IE versions implement a flawed box model.
I'd also say that a lot of all browser incompatibilities originate from a sub par understanding of the box model and float/clear, block/inline.
Having said that, I of course do not deny that it is IE, rather than the developer, that is the real problem, but I usually seek to avoid browser incompatibilities by using HTML structures that not even IE could miss-interpret, rather than through CSS hacks, and I've found that that is often quite doable.
I am pulling my hair trying to find a fix for this problem. If you go to this site you will see that (under IE) the slider and the menu on the top is broken. Works fine under all modern browsers.
Any idea how to fix this? Thanks.
Edit: Want to add that the original site design works fine under IE. I did a massive amount of editing under the hood and somewhere along the line this one was broken that I can't seem to find a fix for. Since I did a lot of customization, I think it seems unfair to ask the original author for a fix (and he is not very responsive either).
The document invalid. In particular, there is a <style> element before the Doctype. This triggers Quirks mode and causes browsers to become very inconsistent (e.g. IE emulates a log of bugs from IE 5.5).
Always work in standards mode and perform basic automated QA.
I can't check it for you, since I've not got access to IE right now, but I've often found that adding position:relative to misbehaving elements is something of an IE magic bullet.
No fix but a lead: the issue with the menu bar is one of IE's mysterious float positioning bugs, as can be demonstrated by putting <div style="clear: both">xxx</div> after the navbar ul. (Note that it won't work if the div has no content!)
stuff about box model deleted: as David Dorward mentions this is caused by quirks mode, and moving the style down past the doctype causes the slider to behave sensibly.
I'm having major rendering issues in Safari with the web application I'm working on. Most of the design is done with divs using absolute positioning. This renders fine on Internet Explorer, Firefox, Chrome, Opera, Netscape, and konqueror. In Safari, it's just a jumbled mess.
Does Safari lack support for absolute positioning of div elements?
What is the best way to trouble shoot and find out what is going on with the safari browser?
UPDATE: I'd like to note I did find the issue, and I would like to thank everyone that gave suggestions. It was the WebKit's "Inspect Element" that gave the most useful information. It appears that their were conflicts with inline styles and styles from the CSS. While safari grabed the styles from the .css file, the rest of the browsers were using the inline styles. i was able to see those conflicts with the information in the tool that was suggested.
The problem may lie somewhere in your JavaScript; one of the most noticeable things about Safari is that it likes to stop executing JavaScript after any errors.
CSS is likely not the issue, since Safari has better standards and CSS support than any other browser out there (alright, I said it.)
Use the built-in Web Inspector in a recent nightly build of WebKit to track down your issues.
1. Safari's support?
Safari is actually a decent browser. If it has its flaws, they aren't any worse than those of any other browser, and they aren't of the class of the old IE browsers, which had very serious problems and lacked even basic support for web standards. To answer you question specifically, yes, it does support absolute positioning.
Safari can certainly render modern X/HTML CSS designs, and since your audience is largely using Safari anyway, you may as well forget the notion of dismissing the browser. It's a good browser, and in any case we're powerless to change it. We simply need to take care of these bugs, whatever they are.
2. How to go about debugging?
Without having a specific example, it's not something anyone can really help you to do. It seems fair to say that you're having some issues controlling css-based layouts. You may have some invalid markup, which in some cases could produce the kind of extreme browser-specific abnormalities you've described.
Start with the basics. Validate your markup and CSS.
Markup Validator
CSS Validator
Make sure you're rendering in standards mode.
Seek out answers to specific questions
If everything validates and you're still having problems, you'll have to track them down one by one. Even if you rebuild the page, piece by piece in Safari in order to see where things begin to unwind, it will be worth it to do. If during this process you really don't understand why a certain behavior exists, you'll at least have a specific question that you can use to poke around for answers. It may be answered already on SO, and if it isn't, you can ask it.