Both IE9 and Chrome14 log TBODY
as the tagName
of the element inside the <table>
The HTML5 spec on <table>
clearly states :
followed by either zero or more tbody elements or one or more tr elements
Furthermore. The HTML5 spec on <tr>
clearly states :
As a child of a table element, after any caption, colgroup, and thead elements, but only if there are no tbody elements that are children of the table element.
Why are browsers corrupting my DOM and injecting a <tbody>
when
- I did not ask for one
- It's perfectly valid without one
The answer of "backwards compatiblity" makes absolutely zero sense because I specifically opted in for a HTML5 doctype.
You're completely missing the part in the HTML5 spec that specifies how the tree is constructed.
The spec allows you to write a
table
without thetbody
element as it's implied. Just like if you skip thehtml
,head
orbody
opening or closing tags, your page can still be correctly rendered.I assume you'd like the DOM to contain a
body
for your content should it be left out for any reason. The same goes fortbody
. It's added in because it explicitly assumes you forgot to add it yourself.The rules for table parsing
From my experience, browsers don't differentiate between HTML5 and HTML4 documents. They behave the same for both. The
<!doctype html>
doesn't trigger any special behavior in browsers.And also
<!doctype html>
is not reserved for "HTML5 documents" - it's just the simplest possible doctype which triggers standards mode.Much of this comes about because HTML5 merges the successor to HTML 4 and XHTML 1.x into a single specification.
When XHTML 1.0 was introduced and browsers started to experiment with using an XML parser, they hit a problem. Authors were used to writing
<table>
s without<tbody>
s. Since an XML parser isn't allowed to infer tags like HTML parsers did, the best way to help authors to transition to XHTML (which seemed like a good idea at the time) was to get the tables to render properly by allowing<tr>
s to be the direct children of<table>
inside the DOM. (The DOM is as much as possible the same, regardless of whether it originated from an HTML parse or an XML parse.) So the browsers implemented support for this.Now the HTML5 content model is shared between the HTML and XHTML serializations of HTML5, so it has to allow for both arrangements, i.e. with or without tbody.
On the other hand, in the section on "The HTML Syntax" (which does not apply to the XML parser), it makes clear that an HTML parse will infer the tbody tags.
When
<table><tr><td>my text</td></tr></table>
is served astext/html
the table structure created in the DOM will have the tr as a direct child of a tbody which is the direct child of the table. The HTML5 content model says this is OK.When
<table><tr><td>my text</td></tr></table>
is served asapplication/xhtml+xml
the table structure created in the DOM will have the tr as a direct child of the table. The HTML5 content model says this is also OK.It is also possible to create a tr as a direct child of table through scripting. For the same reason, browsers will treat this as a table row as most people expect it to.
This is for "historical reasons" (i.e. backwards compatibility, something which is very important to HTML):
Please note that this quote is from the "HTML Syntax" section. This section applies only to documents, authoring tools, and markup generators and explicitly not to conformance checkers (which need to use the HTML parsing algorithm).
So: The specification says that using
tr
outsidetbody
is allowed as per the content model and the parsing specification, but anything that generates HTML (including YOU) should usetbody
.Backwards compatibility is not just about the doctype, scripts might rely on a
tbody
element being there.However, browsers don't differentiate between versions of HTML. HTML documents with HTML5 doctype and with HTML4 doctype (with the small exception of HTML4 transitional doctype without URL in FPI) are parsed and rendered the same way.
I'll quote the relevant part of HTML5 parser description: