A big problem with HTML and HTTP is the fact that error handling has always been undefined (the current HTML spec is the first real attempt to define error handling!) — so different people implement different things, and then when you end up with a single implementation with ~90% marketshare, everyone has to reverse-engineer that (and probably not perfectly!). Combine this with the fact that the majority of implementers of HTML and (to a only slightly less extent) HTTP are web developers who just want to get stuff working — they've never read a page of the spec in their life. So, guess what, they end up relying upon client's error-handling (typically the intersection of clients they care about — which when IE had 90%+ marketshare was often just IE, then see above about reverse-engineering).

The other big problem is the lack of generic test suites for the standards — far too often each implementer ends up writing their own tests, and then not sharing them (the IETF still has no real general infrastructure for hosting testsuites for RFCs!). At least around the W3C, there's been a relatively large movement in the past three years or thereabouts towards developing shared testsuites, in large part down to various Microsoft and Opera people (myself included, in the early days, as a disclaimer) and several WG chairs (trying to push specs to REC — which nowadays requires two interoperable implementations, and hence practically a testsuite), so things are at least slowly changing there. But there's still a lot of work to be done — and it's one area where improvements can have large effects, as it increases the consistency of all implementations, and makes it easier for smaller, and newer, competitors to enter the market.