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.
Related
The more and more we venture into the wonderful world of CSS3, the more and more we all get annoyed by the fact that these features require a MASSIVE amount of browser prefixes to allow compatibility with some older browsers. This problem becomes quite apparent even for small sites, where we need 4 or 5 CSS properties for the exact same effect. A common example would be the background property for gradients.
I know that there are scripts that can help with this issue, but before resorting to those, is there a pure CSS fix that would allow you to work around the prefix issue, or at the very least, some sort of method to keep the extra amount of typing to a minimum? That is, combining things, shorthand, whatever. CSS files can easily double with CSS3-rich content.
I totally agree to the excessive code need to accomplish the same effects in CSS3 but that issue is on the browsers side as other comments stated.
One design practice/tool/technique i think best to follow is using LESS when writing css.
I see the The possibility of over coming this issue (for now) with it. Checkout it out here. http://alittlecode.com/handling-multiple-css3-transitions-with-a-less-mixin/.
If you are not sure what is LESS then check this out - http://www.lesscss.org/.
Yes it is pure CSS from my perspective, but no as stated before, it won't reduce the size of files.
There are some eye-candy experimental CSS like border-radius (rounded corners) and gradients that I wish to use on my page. Unfortunately Internet Explorer does not support any of that yet. At least border-radius is coming on IE9, no word on gradients yet.
So would you recommend just leaving IE alone (most of my users will be on FF or Chrome anyways) or use images to "fix" the presentation for IE? Is it even worth it? Because I know that not only is a pain in the behind but might also break styling on other browsers.
So, to hack or not to hack?
Although this question is a bit subjective, my answer would be not to hack. CSS3 was made to be backwards compatible, and that means it will degrade gracefully if a browser doesn't support it. That for me is the way it should be. I mean, why use CSS3 if you're still planning to hack it anyway? In that case just use the plain old CSS2 tricks like javascript rounded corners or images so you do't have to hack per se.
Terminology quibble: using images to imitate CSS3 features in IE isn’t really hacking. Any visual effect that isn’t directly supported in CSS will need to be implemented in images.
But to answer your question, it depends:
If few enough of your audience use IE, then you can ignore it. Figuring out how few is few enough is up to you/the site owners.
If not:
If the border-radius effects aren’t a key part of the site’s branding, then I’d suggest you just let IE ignore them and use square corners. No-one browses the web with two browsers simultaneously, and no-one cares if your site looks a little bit different in IE 6, as long as the buttons are in the same place and everything works.
If they are a key part of the site’s branding, or your client insists on the site looking the same in IE 6, then you’ve got to achieve the look in IE 6. So, either:
use border-radius, and use conditional comments to include a stylesheet for IE 8 and below with code to imitate the features
don’t bother with border-radius — use the code that works in IE for all browsers. This will avoid you having to maintain two sets of code, but it will mean that all browsers have to download the images you’re using for IE, thus making them perform slightly less well.
I don't think its ever a choice between 'hacking' and not implementing it at all across all browsers, and I'm surprised nobody has mentioned one of the real life-saving 'feature' (I won't consider it a hack, since it is a brilliant method for backward compatibility): Conditional Comments
Not only does it help with annoying IE bugs, it also allows you to define less desirable, but still 100% valid methods for getting certain effects to work, like image gradients with repeat-y instead of CSS3 gradients, or tiled semi-transparent pngs for IE7 and 8. Really, if you want to, IE shouldn't be the one single factor that will limit your ability to experiment with CSS3.
if you do not want images, IE hacks or a seperate stylesheet you could always check out CSS3Pie: http://css3pie.com/. It's not perfect, especially not when you want some gradients & shadows but it can deal with rounded corners pretty easily. There are similar IE behaviors out there but I think this one has the most active development at the moment.
There are hacks and then there are hacks. I interpret a "hack" as being something that exploits a flaw in the browser, such as the descendant selector hack in IE (using >). Those types of things break when the browser is updated.
I don't consider using images to create nice drop shadows or gradients to be a hack. It may not satisfy the requirements that you are doing everything semantically, and you may feel queasy about resorting to using an image for something that an image should not be required for, but the reality is that there's simply no choice - no way to do everything the clean, no-images way - if you want pretty gradients and shadows on the majority of people's browsers (Internet Explorer being that majority).
If you consider the rounded borders or gradients to be just optional eye-candy then by all means don't worry about IE. But if you consider that it actually does make your design look good and you don't want the majority of your users* to miss out, then go for it.
*Depending on your audience, IE may or may not make up a majority of your audience I guess.
That really depends on how important those features are to the look and feel of the site, or rather how important the client and design team feel they are. Additionally its a quation of how much is this going to bloat your markup and CSS - ie. depending on how the effects need to be built in the context of the design how much of a hassle is it going to be?
Normally in this case im in favor of progressive enhancment, ie. come up with something suitable but it doesnt need to be a 1-to-1 to the composite art. Again though, this is a decision you as a developer will ever really be in a position to make on your own (well, unless youre also the designer).
I found this very interesting:
http://matthewjamestaylor.com/blog/ultimate-3-column-holy-grail-pixels.htm
He avoid using horizontal margin and paddings to avoid problems with IE. I think he "fakes" padding using relative positioning.
Have you ever done something like this?
I'm a missing a common trend against IE hacks?
Does this practice have any drawbacks?
That example is outdated.
Problems with margins and paddings like that were a problem with the broken box model of IE5. In later versions of IE you will only get that broken box model if IE is in quirks mode. That's something you should be avoiding at all cost. Use the right doctype!
The example you linked actually relies on that broken box model. He has an updated version that doesn't:
http://matthewjamestaylor.com/blog/holy-grail-no-quirks-mode.htm
But what kind of IE problems are you actually trying to address? Do you specifically want a 3-column layout like in the page you linked to? Do you want general solutions for IE layout problems? Or do you want to be able to forget about IE altogether?
The most important thing to know about when dealing with layout and IE6/7 is its hasLayout property. Read On having layout for all the details on that.
If you are specifically looking for tools that can help you build complex layouts compatible with all browsers, you could have a look at grid frameworks like YUI Grids or Blueprint. But I can't say I'm a fan of those, since they tend to result in unsemantic div soup.
If you don't mind a little (experimental) JavaScript to fix up your entire website automagically, you could give IE7.js a try. I've used this, though it definitely has its quirks and limitations, so use at your own risk.
To come back to your original question, though, relative positioning is no ultimate solution for anything, it's just one of the tools in the box. Understand it and use it when it's appropriate. See, for example, Sitepoint's CSS layout and formatting reference. And as dry as it may be, I find the CSS specification to be invaluable, especially the chapters on the visual formatting model details.
Looking back at Stackoverflow podcast with Litmus (Podcast 78). The podcast discussed briefly the browser incompatibilities and quirks, especially with IE6 (a claim echoed everywhere). Litmus solution is to render the page in all the different browsers and look for differences.
However, I wonder how much incompatibility can be detected by simply analyzing the html and css directly, without actually rendering it.
I'm quite a newbie in this field. But I saw many references out there ... that document the IE 6 bugs and limitation, and how to avoid them when writing new documents.
If that's the case, then can a tool be made to validate and analyze the CSS and report any potential compatibility problems with the CSS?
Are there some incompatibilities that cannot be detected (due to lack of documentation) and potential limitation of such tool (when interacting with javascript and such)?
When we were developing Browsera, we tried to go about detecting cross-browser issues by looking at CSS styling alone. The problem is, it's the interaction between elements that causes the problem, rather than a specific style.
For example, if it were always the case that setting a margin would result in a double-margin, it would be detectable. However, the double margin bug in IE only occurs when there is a float in the same direction, and only for the first element in the row.
In addition to many of the IE6 layout engine issues, a lot of issues we detect are caused by different default stylesheets of browsers. For example, default margins and font size/rendering vary widely across browsers, which is probably the number one cause of layouts that look "not quite right" when you open them in other browsers.
The page seen by an Internet Explorer user is in fact built by IE parsing html and css; so, by definition, it is possible to build a tool that, knowing IE bugs, report potential problems.
Anyway, I don't think it would be easy.
Sure it can, but that's not the point of Litmus's business.
You can analyze a site and report on all the stuff that would render differently, but that wouldn't help much. Litmus's business is not designed to let you know what stuff is incompatible, it's designed to show you how it will be rendered, so you can figure out if and where your site needs improvement.
Making a website look exactly the same across all browsers is very hard, and takes a lot of resources. Often you'll need to compromise and make sure your site still looks decent on all these browsers.
No analysis tool can tell you if your site still looks decent.
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.