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?

  • 7
    You might find Joels article, Martian Headsets to be of interest. Also of special note is RFC 793: Robustness Principle, which explicitly states that TCP implementations should try their best to parse rubbish. This principle has since been applied to browsers. – Brian Jun 7 '13 at 19:30
  • 25
    @Brian: Robustness means you should not fall over when you receive crap. It does not mean you have to make sense of crap. – Marjan Venema Jun 7 '13 at 20:10
  • 2
    XHTML does use strict parsing. – user16764 Jun 7 '13 at 22:07
  • 3
    Is it just me, or are none of these answers very satisfying? – gsingh2011 Jun 14 '13 at 23:01
  • 2
    @gsingh2011 None of the answers are satisfying, but my answer is the truth. Some of us here were active on the net that long ago :-) But yeah, it's astonishing how much junk we're left with for such simple reasons. – Ross Patterson Apr 26 '17 at 23:48

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!

  • 7
    +1 yes, that's how it all started, in vi or notepad. With most pages being copied from bad example code, it never got better. Plus the WWW boomed, so anyone who could type became a web developer and it was all about getting in done fast. – jqa Jun 8 '13 at 3:32
  • 1
    Apparently, this answer in conjugation with @Jukka's comment give the best possible explaination – Shubham Jun 8 '13 at 19:19

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.

  • 7
    Well, I don't think anyone would serve up HTML that throws up errors. WHy do you think a compiler assuming code is any diffrent from a browser assuming HTML. – Shubham Jun 8 '13 at 12:09
  • 1
    I agree with Shubham here - "since we're dealing with input from a source that we have no influence on" is false, the influence is indirect but some web sites still support IE6 because of that influence. – Steve314 Jun 8 '13 at 17:22
  • 2
    @Shubham: A compiler is different because its purpose is not to transform machine-readable source code into a human-digestible form, but to to transform human-readable source code into something that is more convenient for a computer (machine code or some intermediate format). With the compiler, you fix the input and you're glad the code didn't make it into production. With the browser, you curse the browser maker or the website author, but either way, you don't get to see the page. – tdammers Jun 8 '13 at 20:45
  • 2
    @Shubham: Generally the user of a compiler will have control over the source code being compiled. That is generally not the case with web pages. – supercat Sep 2 '14 at 16:28

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 .

  • 15
    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
  • 3
    @GrandmasterB - I think you miss the point - Even where was just one browser in the market - it didn't do strict parsing. – user93353 Jun 8 '13 at 7:14
  • 3
    Funny note: you say that if a browser is unable to parse a invalid site, it will lose market share. But just look at ie: however bad it is, it doesn't lose market share. It just forces poor developers to write dirty hacks in using old APIs... And don't get me started on it's versioning scheme... – Max Jun 8 '13 at 10:20
  • 3
    In the beginning, browsers were written hastily to deal with a markup language that wasn’t finalized and had no official specification – there were no strict parsing rules. (HTML 2.0, in 1995, was nominally SGML-based, but it was too late to have that actually implemented.) – Jukka K. Korpela Jun 8 '13 at 11:09
  • 2
    IE has actually lost quite a lot of its market share. But this probably has little if anything to do with strict parsing. IE, with its oddities, ruled the web long enough to force other browsers largely imitate its oddities, because so many pages would otherwise fall apart. – Jukka K. Korpela Jun 8 '13 at 11:11

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.

  • The HTML syntax was indeed based on the SGML Reference Concrete Syntax for the form of its markup. But SGML itself did not have elements for marking up documents that HTML could borrow, The HTML element set actually resembles that of IBM's GML document markup language, transliterated into the SGML RCS. – Ross Patterson Apr 27 '17 at 0:04

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.

  • 6
    Even before IE came into the market, Netscape never did strict parsing. I remember Netscape from early 1997. – user93353 Jun 8 '13 at 4:10
  • Even if there were clear standards, it would be difficult for a browser to distinguish between tags which were legitimately defined after the browser was released, versus tags which have never been and never would be legitimate. If "optional" tags which enhanced a document but were not required for its semantic correctness included the version number of the standard which implemented them, then a browser which implemented version 23 of the standard could silently ignore an <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)


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.