1 回答
HTML places certain restrictions on which elements can be nested in which other elements. Sometimes browsers will happily construct a nonsensical DOM out of certain nesting scenarios, such as a <div> directly in a <ul>. Other times, they absolutely can't because of other written or unwritten parsing rules, such as <p> elements never containing any other block elements, not even other <p> elements (this is implied by the spec), so they have to work around it by changing the DOM to something that they can work with, resulting in the behavior you observe.
Because you cannot nest <p> elements within one another at all, what's happening here is that this element:
<p> Some line of code </p>
is causing this other element to be terminated:
<p>
This is a sample paragraph with a code block:
<code>
Since there's an empty <code> tag in there, it's closed, and the containing <p> closed as well, because a subsequent <p> start tag will automatically close a preceding <p> start tag:
<p>
This is a sample paragraph with a code block:
<code> </code>
</p>
At this point a browser has to deal with the fact that the <code> and <p> tags are now effectively in the wrong order, but still nested. To compensate for the restructuring of the first "outer" <p> element, and the fact that there was going to be a <code> tag before the second "inner" <p>, it inserts <code> tags into the second <p>, turning its contents into code:
<p>
<code> Some line of code </code>
</p>
Since browsers do seem to allow <p> within <code> for whatever reason (note that at this point the <code> is still not yet explicitly terminated with a </code>), the browser builds the rest of the DOM as follows, before continuing on its way:
<code>
<p> Another line of code </p>
</code>
This is probably consistent across browsers for legacy and cross-browser compatibility reasons; some of these legacy parsing rules have been retconned into sections of the HTML5 spec as well. Unfortunately, I'm not a browser implementer so I can't list out all possible scenarios; on the other hand, it's unwise to rely on such details considering the markup you're writing is invalid in the first place.
And, finally, today's highly relevant xkcd (of course):
