Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am pretty much unaware about the detailed computing history that surrounds internet but it has always made me think why strict parsing was not chosen when creating HTML. Browsers accept any rubbish you write and try their best to parse it. The process, if I am not wrong, hinders performance, allows people to write insane markup, and also allows the obsolete features browsers support because of legacy reasons.

Is there a specific reason for why HTML is not strictly parsed?

share|improve this question
6  
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
16  
@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
1  
Is it just me, or are none of these answers very satisfying? –  gsingh2011 Jun 14 '13 at 23:01
    
@user16764 only if served as XML. Served as text just got lumped into a general "standards mode" that basically rendered all the doctypes completely pointless. Which is why there is now only one. (which, see my answer can be served as XML) –  Erik Reppen Jun 14 '13 at 23:24

6 Answers 6

up vote 27 down vote accepted

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!

share|improve this answer
2  
+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. –  james Jun 8 '13 at 3:32
    
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.

share|improve this answer
5  
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
    
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
1  
@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

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 .

share|improve this answer
8  
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
1  
@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
1  
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
2  
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.

share|improve this answer

this is partially a historic remnant of the browser war

IE and netscape competing to take over the market 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.

this means that if you now create a browser with only strict html parsing 99% of the sites out there will just not work.

share|improve this answer
3  
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

Well we tried to establish a nice strict option in the 000s but it didn't pan out because piss-ant know-nothing professional devs following "best practices" blindly, blamed the browsers when their incompetent 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 off in favor quirks mode. 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.

http://mathiasbynens.be/notes/xhtml5

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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