First of all, the h1 to h6 elements always required their opening and closing tags for verification, as early as HTML 3.2 :
h1 , H2 , H3 , H4 , H5 and h6 are used for document headers. You always need start and end tags.
Therefore, both pages in the link and your example are invalid.
However, it is interesting how the browser handles both cases differently (and yes, closed <h3> tags are a problem):
In any HTML DOM, h1 to h6 elements can never be children of each other, just as p elements can never be children of each other. Any opening tag <h1> to <h6> that immediately follows any such closed opening tag will implicitly close it, and only after that. Thus, all the H3 elements in your example are really related to each other, and not consecutive descendants.
However, what happens on this page is that the H3 elements are not siblings of each other. Instead, they are all separated by table cells, font elements, etc. This is quite a mess (although you can probably expect this from a page created with Microsoft FrontPage 1 ).
However, while the <tr> and <td> tags have their own closing tags, this does not mean that the <h3> tags between them implicitly close. They are still open! Since none of the <h3> tags are closed, and there are intermediate <font> and other tags that encountered H3 elements, the result is that the H3 elements contain all of the following as descendants, but not directly as children, despite <tr> and <td> elements:
h3 font font ... h3 font font ...
As a result, the font size increases with each subsequent H3 , and a significant (ha!) Disaster occurs. Note that font elements do not matter, since none of them defines the size attribute.
The main takeaway from all this?
Confirm your freakin markup. 2 In particular, close all freakin tags (except when closing tags is prohibited).
Despite the fact that the page and in your example doctype HTML 3.2 is used, which starts the quirks mode, it should be noted that this behavior is compatible both in quirks mode and in standard mode. In fact, the HTML5 specification contains a section devoted entirely to parsing and the DOM tree to establish stone-style browser behavior regarding invalid markup (for compatibility with legacy markup and all that). Browsers are expected to follow this specification even in standard mode, therefore this will be consistent behavior in both modes in most browsers.
It has a subsection that contains a rule on how to deal with this specific situation:
A start tag whose tag name is one of: "h1", "h2", "h3", "h4", "h5", "h6"
If the stack of open items has an element p in the button area, then act as if a leaf tag with the tag name "p" was seen.
If the current node is an element whose tag name is one of "h1", "h2", "h3", "h4", "h5" or "h6", then this is a parse error; pull the current node from the stack of open elements.
Insert the HTML element for the token.
This means that if the parser encounters only the header tag, while it is currently in the open header element, then a parsing error occurs and it must close the previously opened header element before entering this new header element, what happens to your example. Otherwise, nothing special happens (i.e., the parser should continue as usual).
However , please do not rely on this . The parsing error is still an error; Be nice with the parser and not throw errors at it just because you can. Just write the correct code and everything will be fine. Of course, when browsers continue to go bad even after you have verified your code, you may be worried.
1 Which, incidentally, was my first HTML editor ... I was 9.
2 Do not overdo it, but do not neglect it.