2

Possible Duplicate:
Cross-browser CSS

Ok, so the question might be somehow a little confusing. I'm gonna try to put it in a much simpler way so "you" can understand my point of view.

All browsers are different. Every browser interprets the CSS rules diferent, which drives to different results. Some times the results are good other times and much often results are totaly unexpected. The case of IE can lead to the worst scenario possible!

Many often, developers are forced to detect the browser to apply a specific css style! This can be achieved with javascript support. Anyhow, some people say that this method it's not enough to prevent disasters... others think that the best way to deal with this problem it's to rely on Object detection instead.

Well, I don't know which one is best... Please feel free to give you opinion based on examples. As always, thank you.

UPDATE

The case of IE can be very simple to deal with conditional statments but, safari can't be treated the same way! So I leave this link: http://quirksmode.org/js/support.html to clarify my point of view...

Community
  • 1
  • 1
obinoob
  • 677
  • 4
  • 13
  • 34
  • 1
    Do you have a specific CSS problem or are you just a pessimist? – Town Jun 16 '11 at 15:34
  • :) neither, at the moment I'm writing an website to a project and need some good advices to deal with the problem of different browsers, particularly with safari and IE. – obinoob Jun 16 '11 at 15:37
  • You might want to look into Modernizr. – Pointy Jun 16 '11 at 15:39
  • Can you point out specific problems that you have with Safari? – RoToRa Jun 16 '11 at 15:45
  • several... but I'm experiencing one very annoying! I'm trying to place "exactly" in the same spot! But with no success at all. With Mozilla, chrome, opera fine but IE and Safari are really an headache. So I thought it was better ask pro's how to deal with different browsers behaviour and it seem a very hard answer to get... – obinoob Jun 16 '11 at 15:57
  • @FCC-PT: Unless you're dealing with bugs in browsers, you handle it by properly understanding what's going on. Try making a new question with a specific example of what's not working. State which browsers/versions you're having problems with, and provide a [jsFiddle demo](http://jsfiddle.net/) of your code. – thirtydot Jun 16 '11 at 16:39
  • See answers here.. http://stackoverflow.com/questions/6342881/keeping-sites-looking-the-same-in-ie-chrome-and-firefox/6343170#6343170 – Kon Jun 16 '11 at 15:36

9 Answers9

5

I personally don't believe in browsers sensing for CSS. In my opinion, it's a waste of time. It takes extra time to code, extra time to change, and creates an extra layer of headaches. Plus, when do you stop? AOL browser? Some random flavor of the day for a 15 year old version of linux used by 12 people in Iceland?

I also don't do hacks. Some will make their way in via Jquery's CSS or outside code I incorporate, but I don't personally write them. They don't validate, so they weren't meant to be in my mind. Javascript tricks are nice, but for styling I don't rely on them because they're not 100% reliable. If it's not gracefully degradable, it's not an option.

So, to combat the issues I do the following:

  1. Clean, valid CSS
  2. Reset (some of the time)
  3. Grids (often, via Blueprint or 960.gs)
  4. Dead reckoning of elements. This means avoiding the graphic designer mentality of 100% pixel perfection and designing for elements that can change as the web often does. Forget box model for a minute, fonts render differently too, and that will never change.
  5. I avoid absolute elements like the plague. 99.5% of everything can be done relative if you try.
  6. Cutting Edge...not bleeding edge. The cool new hacks are nice, but they aren't supported yet. So, they are last case scenario for me. It HAS to be this way for my large (well paying) corporate clients.
  7. Intelligent design. Let's face it folks, if you design FOR THE WEB, you'll have an easier time making it so. If a designer converts a print design for the web, it's nearly always going to have --issues--. Can they be worked through? Sure, and it's profitable for us. But intelligent design in the first place solves all sorts of issues.

The name of the game is progressive enhancement, folks. If IE doesn't support rounded corners, they get square corners. After all, the standard rounded corners are valid HTML. If they have a problem with it, they can upgrade or change. Sound harsh? Sure it is. But we have a very clear standard (set by w3c) to maintain, and it's our job to do it. It's the only way to hit the mark on this moving target.

bpeterson76
  • 12,918
  • 5
  • 49
  • 82
  • hum, interesting point of view :) – obinoob Jun 16 '11 at 16:02
  • You stop with the *worst browser* that [still has some market share](http://gs.statcounter.com/#browser_version-ww-monthly-201005-201105), which depending on the project is probably IE6 or IE7 or IE8. **Not ever** using *any hacks* is not the optimal method. A great example of when to use a hack is when you're using `display: inline-block`, and you need IE7 support: `display: inline-block; *display: inline; zoom: 1`. `*property` is a "safe hack" - it's not going to cause *any problems*, other than breaking validation (which is fine). More on this: http://mathiasbynens.be/notes/safe-css-hacks – thirtydot Jun 16 '11 at 16:08
  • +1 Because I agree with you, overall. Though, like Thirtydot, I think some hacks are necessary. I believe in using them sparingly and sandboxing them to their own IE stylesheets. Also, I find your rationale for #6 a little...off. You seem to use "not supported yet" to mean that at least one browser doesn't support it. Using that rationale, you shouldn't be using quite a few CSS2 things, as well, especially if supporting IE6/7.... – Shauna Jun 16 '11 at 16:24
  • @Shauna, true, but I consider Internet Explorer an edge case. But there is plenty of cool CSS3 that's not even supported by all the "good" browsers yet either. We're getting there, just not quite production level yet in my mind. – bpeterson76 Jun 16 '11 at 16:27
  • As you said, designing for the web is the name of the game, and doing so include progressive enhancement, which includes the CSS3 stuff, in my opinion. Under the definition of hacks = exploiting browser bugs, vendor prefixes aren't hacks (especially as they're designed to be able to be phased out). – Shauna Jun 16 '11 at 16:31
  • @bpeterson - That's what's nice about the way CSS is developed. You don't have to wait for everything to be accepted and supported, but rather, pick and choose what to use. `border-radius` and `box-shadow` are good examples of things that can be used pretty safely. It's a matter of discretion. Like you mentioned, though, it also depends on your circumstance. For you, specifically, it might be out of the question because of your clients. I have more flexibility, because mine better understand progressive enhancement. – Shauna Jun 16 '11 at 16:33
3

Two things. First, make sure you include a DOCTYPE. If you don't, browsers will default to quirks mode, and their interpretation of styles will be different. This way, you can minimize the different CSS interpretations of your page.

Second, I'll point out that IE (the big offender, in my experience) supports conditional comments, so you can include styles for specific IE versions like this:

<!--[if lt IE 8]>
<link rel="stylesheet" href="iehacks.css" type="text/css" />
<![endif]-->
Katie Kilian
  • 6,815
  • 5
  • 41
  • 64
  • I believe that one of my major bugs it's due to the fact of not using doctype ;) thank you... – obinoob Jun 16 '11 at 19:05
  • @FCC-PT: If you don't use a doctype, then IE is emulating the ancient IE5 ([Quirks Mode](http://en.wikipedia.org/wiki/Quirks_mode)). As you can imagine, that makes it *diabolically impossible* to write cross-browser CSS properly. The blunt truth here was that the browsers were not to blame: you did not know what you were doing - not adding a doctype is an elementary mistake. – thirtydot Jun 16 '11 at 19:09
  • I used to "code" under dreamweaver, therefore I never bothered with doctype between other sort of thing tipical from ide's WYGIWYS... at the moment I realized that dreamweaver it's not the right way to follow :) besides the site manager :( and with my decision simple problems like this one started to make sense. Anyway, I knew that doctype is important to define the type of document but I never though about how doctype could affect the several browsers. Now I know! Thank you for that precious information. – obinoob Jun 16 '11 at 19:46
  • I wouldn't sweat it; everyone makes elementary mistakes when they're just beginning. And starting to hand code HTML counts as beginning, in my opinion, even if you're already somewhat familiar with it. – Katie Kilian Jun 16 '11 at 20:47
3

All browsers are different. Every browser interprets the CSS rules diferent, which drives to different results. Some times the results are good other times and much often results are totaly unexpected. The case of IE can lead to the worst scenario possible!

You should be able provide the exact same CSS to all browsers (I'm talking about CSS 2.1 here) and get consistent display, with the exception of IE6 and IE7 (and that's because they have too many bugs).

For those browsers, a common practise is to include a new stylesheet using conditional comments with specific fixes:

<link href="forAllBrowers.css" rel="stylesheet" type="text/css" />
<!--[if IE 7]><link href="ie7.css" rel="stylesheet" type="text/css" /><![endif]-->
<!--[if IE 6]><link href="ie6.css" rel="stylesheet" type="text/css" /><![endif]-->

The other scenario is when you're willingly using things that are only available in newer browsers.

In those cases, it's a good idea to use Modernizr to detect support for the shiny new feature you're using.

That way, you can provide a sane fallback for browsers which do not support the feature.

thirtydot
  • 224,678
  • 48
  • 389
  • 349
  • I believe you meant anyhow this method seem to work ok with css rules above the third 3 version... – obinoob Jun 16 '11 at 15:53
  • I definitely didn't mean `gt IE 5` - that would apply it to all versions of IE greater than 5 - IE6/7/8/9 ! I meant what I wrote, which is that all browsers are served the same CSS, and IE7 and IE6 each get their own CSS with specific bug fixes. – thirtydot Jun 16 '11 at 15:57
2

For singling out IE, particularly IE7 and 6 you can use conditional comments to load IE specific styles and or stylesheets.

Most bugs do have viable workarounds. Well formed and standards compliant html/css should display properly in all modern browsers.

Jared
  • 12,406
  • 1
  • 35
  • 39
0

IE Conditional Styles can help you work around imperfections in Internet Explorer.

Town
  • 14,706
  • 3
  • 48
  • 72
0

Excluding JavaScript, there's basically two solutions to this problem. You can mix and match both.

The first solution is to determine the user's browser based on the header in the HTTP request. (Different platforms will allow you to do this in different ways - for example in ASP.NET, the Request object contains this information). You can then serve different physical CSS files depending on the user's browser.

The second way is to use a single CSS file that contains different rules for different browsers. The right rules are applied to the right browsers using various browser-specific hacks. Effectively, this means using CSS rules that only certain browsers understand. More information on this technique can be found here.

David
  • 15,750
  • 22
  • 90
  • 150
  • One should mention that browser sniffing is inherently unreliable and leads to many other problems. – RoToRa Jun 16 '11 at 15:44
  • I'm unaware of them. Obviously HTTP headers can be modified, but normal users aren't going to do this. Can you elaborate? – David Jun 16 '11 at 15:49
  • 2
    Firewalls or proxies that modify the HTTP headers; the need to "keep up" with any new User Agents; Proxies that cache the page/stylesheet and thus deliver the cached version to the wrong browser. – RoToRa Jun 16 '11 at 15:54
  • Last point is interesting. I would not have thought of that. Thanks. – David Jun 16 '11 at 15:58
  • yeah the last point is definitely very interesting never though of that! – obinoob Jun 16 '11 at 19:56
0

Well, for inline CSS, you can do specific hacks such as:

.myclass {
  height: 100px; /* all browsers */
  #height: 100px; /* MSIE browsers */
  _height: 100px; /* MSIE >= v6.0 */
}

Alternatively, you can use comment style conditions within the page and include optional style sheets:

<!--[if gt IE 5]>
<style type="text/css">
  .mystyle { height: 100px; }
</style>
<![endif]-->
Brad Christie
  • 100,477
  • 16
  • 156
  • 200
0

Actually all current, modern browsers interpret CSS very similarly based on the standards. It's usally only IE (6, 7, 8) that make problems, especially if your HTML documents don't trigger Standards-Mode, thus:

  1. Write your pages based on current HTML and CSS standards with a DOCTYPE.
  2. For support of older IE, give them separate style sheets using Conditional Comments.
  3. If there are differences between other browsers, there are usually workarounds. Ask abotu specific problems here or in your favorite CSS forum/group/list.
RoToRa
  • 37,635
  • 12
  • 69
  • 105
0

Just one word: Modernizr.

You should never change the styles based on user's browser, but based on the browser's resource allowed or not.

Erick Petrucelli
  • 14,386
  • 8
  • 64
  • 84
  • That's cool but not what I look for! My experience with frameworks tell me that sometimes It's better write the native language it self like javascript! Anyway you should open the link with IE to see the results :O – obinoob Jun 16 '11 at 15:48
  • 1
    I like the quote from the Modernizr website: "And remember, none of your users view your site in more than one browser; **It’s okay** if it looks and acts differently." – Mattis Jun 16 '11 at 15:51