i wanted to know, if there is a way to describe browser compatibility and things that add up to create differences in each of the browser?
Speaking for myself, it’s not really clear what you are asking for. Are you looking for a list of faults for each browser?
It’s probably better to make good CSS code your reference point, and then take note of any browser failings that might influence your choice of what CSS rules to use. For example, after learning about display: table, it’s handy to know that it doesn’t working in versions of IE prior to IE8.
yes list of faults, actually i have 2-3 yr exp on working on css and browsers compatibility issues but i have to compile a presentation on why it happens. i m technical more than verbal
The sitepoint css reference documents a lot of the compatibility issues with browsers.
why it happens.
Because all browsers are different and have different ways of doing things and although they work closely with the specs their are certain ambiguities within the specs and within the algorithms that each browser uses. Not to mention plain old fashioned bugs of course.
Modern browsers are now closer than they have ever been but they will never be 100% the same and indeed if you use vendor extensions then you are running the risk of using something that is not going to be supported or may be changed drastically.
The biggest problem with browsers is us (coders). 99% of the problems I see on a daily basis are down to bad coding techniques and bad practices from inexperienced designers. Doing things the right way from the start avoids a lot of the bugs that you see. Quite often you will see that dimensions across a page don’t add up and you get the question “why is this bigger in IE?”. Applying the correct dimensions fixes the error and stops the browser having to guess what you wanted. Old IE will always expand an element to accommodate its content whereas other browsers won’t.
Off Topic:
How u doing paul, its been ages
I want to understand how IE like version 5 or 6 compute box model? i know this much that its margin and padding are included in width but unable to understand, how it differs from adding up margins, padding along with the width of content/div.
I’m fine thanks 
You can find clear diagrams and explanations of both the box models here and [URL=“http://reference.sitepoint.com/css/ie5boxmodel”]here which should help.
so what i understand is the box model which e.g
#box{
width:200px;
margin:5px;
padding:5px;
}
will sum up to 200+5+5+5+5 = 220
whereas in IE5 if we take same example it will like 200+5+5=210 (width+margin), but the padding or border will be subtracted from that 210, which will be 210-5-5=200? or will it subtract from 200, the total of width. (maybe i am wrong)
You can ignore margin in your calculations as they are treated the same in both box models.
#box{
width:200px;
border:1px solid #000;
padding:5px;
}
In the IE5 box model (or the border-box value of the css3 box-sizing property):
The space on the canvas that the above element takes up is 200px.
The space available for actual content in that box is reduced by the padding and borders.e.g. 200 - 5 -5 -1 -1 = 188px
In the normal box model (or the content-box value of the css3 box-sizing property):
The space on the canvas that the above element takes up is 212px.
The space available for actual content is the 200px width that you specified as the padding and borders are added outside this width.
I’m not sure why you really need to know this these days as ie5 is dead and is the only browser that had this behaviour (apart from some old opera versions). (However all versions of IE will revert quirks mode if you don’t have a doctype and will use the broken box model.)
I know IE 5 is dead. i just need few solid points on why we face browser to browser problem,as i am preparing presentation on browser compatibility. can u be brief on that?. i know its add up to
1.doc type must be write,
2.understanding box model
3.proper nesting
3.html resets
what are other inconsistency that IE lack,in comparison to firefox
Probably best to read it up here:
1 a)CSS Reference standards mode/quirks mode
1 b)Doctypes
-
Already covered in previous posts
-
Proper nesting is basically using valid code and valid structures so that the browser understands it without having to error handle. Valid code is a must if you want things to work properly.
4)You can read all about the pros and cons of resets here and if you look down the forum there was another post the other day about resets also.
There’s a very old article of mine here that pre-dates resets but talks about the same things.
I think (If I’m reading your questions right) that’s what the other respondents are missing here – you seem to be asking why these inconsistencies even exist in the first place.
When it comes to HTML, that’s actually very simple if you know what HTML was designed FOR. HTML was not designed to create the appearance of a page, it was designed to mark up content so that the user agent (aka browser) could best determine how to show it on target hardware. The very notion of having the same HTML appear the same in all browsers runs entirely against the basic concept of what HTML is FOR. This is why the HTML specification is filled with “may” or “could” or “typically” – but you’ll be hard pressed to find a whole lot of “should” or “must”. Take line-height for example where it “suggests” that user agents “typically should” use a value somewhere between 110% to 130%… Things like default paddings, margins, font sizes – that’s all left to the discretion of the user agent so that the content (the actual important part of the page) can be best delivered and/or customized for whatever hardware you try to show it on – be it a 22x20 VIC=20 display, a plaintext only teletype or daisy wheel printer, right through to todays 2560x1536 displays. This is why semantic markup is how it’s supposed to be written – saying what things ARE, NOT how they should appear… hence my constantly saying “if you choose tags based on the default appearance, you’re probably choosing the wrong tags”.
HTML got away from that with HTML 3.2 as many people making pages started to give a flying fig about anything except 800x600 or larger screen – during the browser wars the various browser makers started making custom tags JUST for that type of target and 3.2 adopted many of them… This basically pissed all over accessibility and since they started out as proprietary tags, they only worked in certain browsers.
To address this CSS was introduced – and that’s where things started to go to hell… since so many browsers had different default paddings, margins and sizes on elements adding CSS into the mix meant you couldn’t trust the defaults to be the same. In many cases (INPUT comes to mine) you couldn’t even apply styling consistently just because Netscape and IE had different default paddings that were separate from the padding CSS declared. (a problem that plagues us to this day!).
Though MOST of the cross-browser issues we face today come from one source - IE… which in version 5, 5.2, 5.5 and 6 were all the most standards compliant browsers of the day – and that’s actually THE PROBLEM. They were implementing standards that were in draft (CSS2) and because it was so useful, developers started deploying websites in it before the specifications were finalized. Because the specs changed you ended up having the box model issue and the doctype trigger in IE6 to try and say “pages that don’t have this probably use the old box model”. The CSS specification is also very vague on the application of CSS to elements, in particular to this day things like form elements are a royal pain… The browser makers are often forced to make the choice – do we fix this so it works as the specification says, or do we leave it alone or add some sort of trigger so the pages made over the past decade don’t break?
Again, take INPUT as an example – Trident and Gecko both treat INPUT as a ‘special’ tag that has a default extra padding you have no control over – one browser declares it it EM, the other declares it in PX (I forgot which is which) and this padding does NOT go away even if you say padding:0;… Both browsers treat them as “special” regardless of if you set display:inline, display:inline-block or display:block. Worse, FF obeys height and ignores line-height on them, while IE ignores height and uses line-height – the specification? DOESN’T SAY WHICH IS CORRECT!!! You get Opera in the mix and it SHOCK treats them as inline-block or block EXACTLY, meaning height works, line-height will work if height is set to auto, and there’s no extra padding apart from what you declare…
… and don’t even get me STARTED about Webkit and form elements.
But really it’s part of why I laugh at the pathetically broken attempts at trying to deploy HTML 5 right now – not only do you have people crapping out pages with the javascript shiv idiocy and not only does it add no really useful functionality (of the entire markup part of the spec there are THREE tags that are useful – of those one is form related, one’s semantic inline, one shouldn’t really be necessary since it only works when .js is on) and set coding practices back a decade or more with the loosening of the structural rules – but worse, it’s browsers and people attempting to deploy draft – the root cause of why we had so many problems making HTML4/CSS2 pages that worked cross browser in the first place with all the IE headaches.
Even more idiotic when you figure in browser engines like gecko adding the HTML 5/CSS3 stuff when they have gaping holes in their HTML 4/CSS2 implementations that just became teenagers. – part of why unlike other developers I actually applauded Microsoft for NOT trying to add CSS3 stuff to IE8 – as maybe they should focus on getting HTML 4/CSS2 working better BEFORE moving on to it? Part of why 9 is so disappointing as sure it adds some of the flashy CSS3 crap, but it’s still nowhere near correct for HTML 4 and CSS 2!
But that’s browser development in a nutshell – if it’s not flashy and trendy, kiss off it ever being fixed… and worse that’s usually twenty times worse on open source projects… See bugzilla 915, Webkits handling of CAPTION, etc, etc… documented bugs that are anywhere from 8 years to 13 years old and remain unresolved in open source projects… making the complaints about a browser that went six years without a development team seem kinda lame.