The actual "why" goes a lot back than people think -- back to before CSS even existed, and having more to do with what HTML is, is for, and why it exists!
See, when Tim Berners Lee made HTML he was dealing with multiple documents in all sorts of different file formats that were proprietary to different hardware platforms. Legal documents, term papers, scientific papers, reports, technical documentation. These file formats often were created to be useful only on one specific set of resolution, output size, or device capabilities, and that got him thinking...
Why not have a document format where you say what things are -- or at least would be -- in a professionally written document, and then have the user-agent (a browser is just ONE of many types of UA) best determine how to convey that MEANING.
That's why HTML is for saying what things ARE, and NOT WHAT THEY LOOK LIKE!!! We got away from that during the pissing contest between Microsoft and Netscape now referred to as "The first browser war" with the train wreck of garbage idiotic nonsense that had no business ever being part of HTML (font, center, align, bgcolor, target, etc) but the entire intent of HTML 4 Strict was to drive us back to a very VERY simple concept:
If you are choosing your HTML tags based on what you want things to look like, you are choosing all the wrong tags for all the wrong reasons.
That's why H1 (at least before HTML 5 started pissing on document structure undoing 20 yeears of progress) is the heading that everything on every page is a subsection of. That's why a H2 indicates the start of a major subsection of the page. That's why a H3 means the start of a subsection of the H2 preceeding it, a H4 means the start of a subsection of the H3 preceeding it, and so forth -- JUST as a HR means a change in section/topic where heading text is unwanted or unwarranted. (and why HTML 5's idiotic ARTICLE, SECTION, ASIDE, NAV, HEADER, FOOTER, MAIN, Aria roles, etc, etc. are pointless code-bloat redundancies that only people who never understood 4 Strict are dumb enough or ignorant enough to use! The WhatWG was utterly unqualified to have created 4 Strict's successor!!!)
Even "B" and "I" have a semantic meaning, as in WOULD be bold or italic for grammatical reasons (legal entity, company name, book title not being cited) and remain in the specification -- and why "STRONG" and "EM" ARE NOT 1:1 replacements for them. When I say "I read Moby Dick" last night I'm not emphasizing "Moby Dick", I'm not citing it, it's just a book title. WOULD BE, doesn't mean it has to or even CAN be conveyed as italic!
Not all devices when TBL created HTML were capable of showing italic, or bold, or different text sizes and weights -- you used HTML to say what things ARE so that the UA can best determine how to show it within the device capabilities and/or user needs.
Which means BY THE VERY REASON HTML EVEN EXISTS there is and should be NO default appearance for any tag. It is ENTIRELY up to the whim of the User-agent maker how to convey that meaning to the user!!!
Therefor when CSS came along, there was no simple unified baseline for "screen media" or any other media target for that matter in terms of a starting point to which CSS could be applied. This is why when CSS was implemented Nyetscape and Exploder both had different defaults for margins, padding, and borders across different elements; thus the "reset" was born to give you that default.
Things only got worse when Microsoft implemented both HTML 4 and CSS before anyone else did for the simple fact that with IE 5 they did it BEFORE either specification was out of draft, or even created specific details for screen media defaults. It was hot, it was trendy, and everyone used it before it was out of draft even though no other browsers were even trying to do it yet... and it put IE squarely in the lead.
Shame the draft bore no resemblance to the FINAL version that came out a while before IE6. Hence the "broken" box model that developers spent a decade and a half pissing and moaning about being garbage, and then creamed their panties wanting it like it was the second coming when box-sizing came along.
So to TRY and implement it properly they used the presence of a doctype as the trigger for using the correct box-model, but the underlying damage was done in the engine and they had too much time and money invested to start over clean like the competitors were doing. That's why IE and Netscape/FF have always been at odds.
The situation is only exacerbated by the fact that no two people can read the legalese of the specifications and come away with the same meaning. IMHO the CLOSEST implementation to what the specs (both HTML and CSS) was the Presto Engine that powered Opera 7 through 10, and why their throwing it in the trash is a true shame. PARTICULARLY with the giant middle finger to loyal fans that Blink based Opera is... which is why I use Vivaldi.
Simply put, the HTML and CSS specifications read like it was written by a lawyer in Finnish, translated to Japanese by a Russian, then Google Translated back to English -- and why it takes a gaggle of lawyers to even decipher it in a consistent manner. Just look at the use of the word "deprecated" as if we're talking down to it like it were a petulant five year old, or "empty" which does not mean what you think it means since:
<div></div>
Is NOT what they mean by an empty tag in the specification.
With it that confusing a mess, AND HTML not actually having a specific default since it's for MORE than just perfectly sighted users on the exact same screen size or device capabilities -- it's a MIRACLE that there's a uniform baseline whatsoever -- and to be frank recent specifications sure as the hell aren't helping when people are diving for implementing draft stuff and new specs when they don't even have the old ones (4 Strict, CSS 2) implemented properly or fully, with TWENTY YEAR OLD bugs/differences still unaddressed.
Have a look at "Bugzilla 915" for a laugh over how pathetic bug fixing in Open Sores software can REALLY be. If it's not hot, trendy, flashy, security related, or someone is willing to put up a bounty, bugs in open source tend to sit there unaddressed. MORE SO when the people using the software aren't qualified to brave enough to modify the code themselves!
When HTML has no default starting out with different values for margins, padding, line-height, borders, even element heights (see form elements), AND the specification itself is written in a aggravatingly vague legalese, AND the various browser makers want to see each-other dead and therefor try to 'innovate' their own ways of doing things and to hell with what anyone else is doing...
in each browser there is something called Browser Engine, this is the heart of any browser. it take the CSS, HTML, Javascript ...etc and drowning into browser screen. it is like a compiler on programming language.
So we have one CSS code and different Browser Engine, some Engine drowning the CSS code with different way than the other engine do, and some Engine support some CSS features and the other not. here is the issue and the big headache for every Front-end developer.
Jason Knight
The less code you use, the less there is to break
Oct 17, 2017
The actual "why" goes a lot back than people think -- back to before CSS even existed, and having more to do with what HTML is, is for, and why it exists!
See, when Tim Berners Lee made HTML he was dealing with multiple documents in all sorts of different file formats that were proprietary to different hardware platforms. Legal documents, term papers, scientific papers, reports, technical documentation. These file formats often were created to be useful only on one specific set of resolution, output size, or device capabilities, and that got him thinking...
Why not have a document format where you say what things are -- or at least would be -- in a professionally written document, and then have the user-agent (a browser is just ONE of many types of UA) best determine how to convey that MEANING.
That's why HTML is for saying what things ARE, and NOT WHAT THEY LOOK LIKE!!! We got away from that during the pissing contest between Microsoft and Netscape now referred to as "The first browser war" with the train wreck of garbage idiotic nonsense that had no business ever being part of HTML (font, center, align, bgcolor, target, etc) but the entire intent of HTML 4 Strict was to drive us back to a very VERY simple concept:
If you are choosing your HTML tags based on what you want things to look like, you are choosing all the wrong tags for all the wrong reasons.
That's why H1 (at least before HTML 5 started pissing on document structure undoing 20 yeears of progress) is the heading that everything on every page is a subsection of. That's why a H2 indicates the start of a major subsection of the page. That's why a H3 means the start of a subsection of the H2 preceeding it, a H4 means the start of a subsection of the H3 preceeding it, and so forth -- JUST as a HR means a change in section/topic where heading text is unwanted or unwarranted. (and why HTML 5's idiotic ARTICLE, SECTION, ASIDE, NAV, HEADER, FOOTER, MAIN, Aria roles, etc, etc. are pointless code-bloat redundancies that only people who never understood 4 Strict are dumb enough or ignorant enough to use! The WhatWG was utterly unqualified to have created 4 Strict's successor!!!)
Even "B" and "I" have a semantic meaning, as in WOULD be bold or italic for grammatical reasons (legal entity, company name, book title not being cited) and remain in the specification -- and why "STRONG" and "EM" ARE NOT 1:1 replacements for them. When I say "I read Moby Dick" last night I'm not emphasizing "Moby Dick", I'm not citing it, it's just a book title. WOULD BE, doesn't mean it has to or even CAN be conveyed as italic!
Not all devices when TBL created HTML were capable of showing italic, or bold, or different text sizes and weights -- you used HTML to say what things ARE so that the UA can best determine how to show it within the device capabilities and/or user needs.
Which means BY THE VERY REASON HTML EVEN EXISTS there is and should be NO default appearance for any tag. It is ENTIRELY up to the whim of the User-agent maker how to convey that meaning to the user!!!
Therefor when CSS came along, there was no simple unified baseline for "screen media" or any other media target for that matter in terms of a starting point to which CSS could be applied. This is why when CSS was implemented Nyetscape and Exploder both had different defaults for margins, padding, and borders across different elements; thus the "reset" was born to give you that default.
Things only got worse when Microsoft implemented both HTML 4 and CSS before anyone else did for the simple fact that with IE 5 they did it BEFORE either specification was out of draft, or even created specific details for screen media defaults. It was hot, it was trendy, and everyone used it before it was out of draft even though no other browsers were even trying to do it yet... and it put IE squarely in the lead.
Shame the draft bore no resemblance to the FINAL version that came out a while before IE6. Hence the "broken" box model that developers spent a decade and a half pissing and moaning about being garbage, and then creamed their panties wanting it like it was the second coming when box-sizing came along.
So to TRY and implement it properly they used the presence of a doctype as the trigger for using the correct box-model, but the underlying damage was done in the engine and they had too much time and money invested to start over clean like the competitors were doing. That's why IE and Netscape/FF have always been at odds.
The situation is only exacerbated by the fact that no two people can read the legalese of the specifications and come away with the same meaning. IMHO the CLOSEST implementation to what the specs (both HTML and CSS) was the Presto Engine that powered Opera 7 through 10, and why their throwing it in the trash is a true shame. PARTICULARLY with the giant middle finger to loyal fans that Blink based Opera is... which is why I use Vivaldi.
Simply put, the HTML and CSS specifications read like it was written by a lawyer in Finnish, translated to Japanese by a Russian, then Google Translated back to English -- and why it takes a gaggle of lawyers to even decipher it in a consistent manner. Just look at the use of the word "deprecated" as if we're talking down to it like it were a petulant five year old, or "empty" which does not mean what you think it means since:
<div></div>
Is NOT what they mean by an empty tag in the specification.
With it that confusing a mess, AND HTML not actually having a specific default since it's for MORE than just perfectly sighted users on the exact same screen size or device capabilities -- it's a MIRACLE that there's a uniform baseline whatsoever -- and to be frank recent specifications sure as the hell aren't helping when people are diving for implementing draft stuff and new specs when they don't even have the old ones (4 Strict, CSS 2) implemented properly or fully, with TWENTY YEAR OLD bugs/differences still unaddressed.
Have a look at "Bugzilla 915" for a laugh over how pathetic bug fixing in Open Sores software can REALLY be. If it's not hot, trendy, flashy, security related, or someone is willing to put up a bounty, bugs in open source tend to sit there unaddressed. MORE SO when the people using the software aren't qualified to brave enough to modify the code themselves!
When HTML has no default starting out with different values for margins, padding, line-height, borders, even element heights (see form elements), AND the specification itself is written in a aggravatingly vague legalese, AND the various browser makers want to see each-other dead and therefor try to 'innovate' their own ways of doing things and to hell with what anyone else is doing...
Is it really a surprise they don't work alike?
Mohamed Binothman
Web Developer
Oct 17, 2017
in each browser there is something called Browser Engine, this is the heart of any browser. it take the CSS, HTML, Javascript ...etc and drowning into browser screen. it is like a compiler on programming language.
So we have one CSS code and different Browser Engine, some Engine drowning the CSS code with different way than the other engine do, and some Engine support some CSS features and the other not. here is the issue and the big headache for every Front-end developer.