I have often wondered why strict parsing was not chosen when creating HTML. For most of the Internet history, browsers have accepted any kind of markup and tried their best to parse it. The process degrades performance, permits people to write gibberish, and makes it difficult discontinue obsolete features.
Is there a specific reason why HTML is not strictly parsed?
The reason is simple: At the time of the first graphical browsers, NCSA Mosiac and later Netscape Navigator, almost all HTML was written by hand. The browser authors (Netscape was built by ex-Mosaic folks) recognized quickly that refusing to render incorrect HTML would be held against them by the users, and voila!
Because making best guesses is the right thing to do, from a browser-maker's perspective. Consider the situation: ideally, the HTML you receive is completely correct and to spec. That's great. But the interesting part is what happens when the HTML is not correct; since we're dealing with input from a source that we have no influence on, really, we have to be prepared for this. Now when that happens, what could we do? We have two options: a) fail, and b) make a best effort to recover from the error. If we fail, the user has nothing but a useless error message, and there is nothing they can do about it, because they don't control the server. If we make a best effort, the user has at least what we could make of the page, and often the guess is mostly right.
The only real problem with this is when you need the error messages, which is typically in a development situation - you want to make sure the HTML you generate is correct, and since "works in browser X" is not equivalent to "correct", we can't simply run it through a browser and see if it works: we can't tell the difference between correct HTML and incorrect HTML that the browser has fixed for you. This is a solvable problem though; there are browser plugins that report standards violations, there's the W3C validator, and lots of other similar tools.
HTML authors and authoring tools produce crappy markup. Browsers do their best with it for competitive reasons: a browsers that fails to render most of web pages in any reasonable way will be rejected by users, who won’t care the least about whose fault it is.
It’s rather different from what programming language implementations do. Compilers and interpreters work on code that can be assumed to be written by a programmer, whereas everyone and his brother can write HTML with minimal training, or without. HTML markup is code, in a sense, but it’s data rather than programming language instructions, and the (good) tradition in software is to be tolerant with data.
XHTML in principle imposes strict (XML) parsing rules, so that an XHTML document served with an XML content type will be displayed only if it is well-formed in the XML sense – otherwise, only the first error is communicated to the user. This never became popular in web authoring – almost all of the “XHTML” around is served as text/html and processed as traditional tag soup in a very liberal way, just with some new eccentricities .
HTML authors and authoring tools produce crappy markup. - they do because browsers accept it. If from the beginning browsers didn't accept it - then these tools & authors wouldn't have been able to get away with producing crappy markup
– user93353
Jun 8 '13 at 3:13
The short of it would be that HTML was based on another non-hyperlinked markup language called SGML often used for documentation and manuals and the like.
From an article about the history of HTML:
Tim had mentioned that some of the early HTML documents were based on an old SGML language that CERN was already using:- We have included in HTML some tags from the SGML tagset used at and once supported at CERN [...] The HTML parser will ignore tags which it does not understand, and will ignore attributes which it does not understand of CERN-SGML tags.
[...] most of the early HTML tags were actually taken from the CERN SGMLGuid language, which itself was a variant of AAP (an early SGML language). For example, title, hn, p, ol and so on are all apparently taken from this language. The only radical change was the addition of the all important anchor () link, without which the WWW wouldn't have taken off.
Taking note of the part I've bolded, basically, they implemented a subset of the tags available in the SGML system they were familiar with, adding the new anchor <a> tag, and choosing to ignore any of the many tags they didn't care about or wish to support for wahtever reason (such as tags for bibliography lists, xmp for "example", "box" tag to draw a box around a block of text, etc). So the simplest way to do that is to be forgiving of markup that is not known by the parser and ignore unknown markup as best as possible, regardless of whether the cause is user typed bad markup, or the quickest easiest way to convert existing documents to this new HTML format is to add some hyperlinks to existing SGML documents, and ignore whatever tags aren't supported or implemented.
This is partially a historic remnant of the browser war
IE and netscape were competing to take over the market and kept releasing new features that kept becoming more and more "awesome", and were force to accept the pages designed for the other browser.
This means that browser accept and ignore unknown tags silently, after the committees started getting involved ... well you have a committee designing stuff and as a result a lot of different versions (with some ambiguously worded specs) where browser want to support most of them, and creating a separate parser for each version would be enormous bloat. So it is (relatively) easier to use a single parser with different modes.
For another part netscape and IE wanted html to be accessible for the common man (as was the fad those days) which means trying to do what the user wanted to be done instead of what he said to do and tripping over every dangling tag.
Making the problem worse is that there are also several "tutorial" sites teaching the wrong thing and thinking they are right because what they teach works.
Ultimately this means that if you now create a browser with only strict html parsing 99% of the sites out there will just not work.
<o24wowzo> tag but balk at an <o23wowzo>, but such a design would have impaired the "human-readable" aspect of HTML.
– supercat
Sep 2 '14 at 16:27
Well we tried to establish a nice strict option in the 000s but it didn't pan out because people following "best practices" blindly, blamed the browsers when their incorrect markup went to pieces in strict mode. And the browser vendors didn't like being blamed.
They claimed it was because they wanted the web more accessible to non-professionals but nobody was being stopped from using HTML 4 in its most lenient form.
That said, you can still serve HTML5 as XML if you desire strict-style layout. IMO it can be a good way to reap the benefits of doing layout or UI work in a stricter mode before you pass it on to other people who may or may not want it as strict without any real risks (barring them ripping the doctype out because they actually favor quirks mode - in 2017 (the time of this edit) they should be shot. So it's still there basically but do some research. I seem to recall there being some caveats that we didn't have with XHTML that didn't really impact layout work. Just don't spread the word that it's "the only way to do it right" or the twits who buy into that kind of talk will dogpile the idea, blame the browsers again, and they'll take the teeth out of the only strict alternative we have left. (2017 edit: I have no idea whether this still works - gave up)
