Even the video element is made awkward by codec issues, thus depending on the browser implementer or underlying platform to function properly.
So, in a sense, you have it exactly backwards. :)
In the modern age, we know that broken and non-conforming markup is the vast majority of content on the Web, and not only does this content depend on certain parsing behaviours, but those parsing behaviours are fairly reliably implemented across browsers. Of course, that interoperability is far from perfect, and took vast effort to achieve (legend has it that in early versions of IE, Microsoft reverse-engineered and re-implemented parsing bugs Netscape didn't even know they had, and later Mozilla had to do a lot of the same work on IE's behaviour). This is a good part of the reason that there's only four reasonably useful HTML rendering engines on a planet of six billion people.
One of the goals of HTML5 is to reverse-engineer and document what it is that browsers actually do to turn tag-soup into an internally consistent DOM tree, in the hope that future browser vendors won't have to reverse-engineer the wheel yet again. For example, ".innerHTML" is a property on DOM elements that allows script to quickly change the content of that element. It's widely used on websites, and supported in all major HTML engines, so you'd think it'd be pretty easy to get right and interoperable, right? Wrong: