Consider removing language suggesting <tr> is a valid child of <table>

[rschristian]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/tr

What specific section or headline is this issue about?

Usage Notes

What information was incorrect, unhelpful, or incomplete?

The <tr> may be placed as a direct child of its parent <table> element

• Perma link

What did you expect to see?

I suppose not this?

Do you have any supporting links, references, or citations?

While <tr> is "allowed" as a child of <table>, all parsers will wrap it in a <tbody>, turning this:

<table>
  <tr />
</table>

into this:

<table>
  <tbody>
    <tr></tr>
  </tbody>
</table>

Saying <tr> "may be placed as a direct child" I think is a bit questionable. Even if parsers will fix this, it shouldn't be done.

Do you have anything more you want to share?

No response

[BrianJDrake]

The parser behaviour you refer to is not fixing invalid HTML markup; it is merely normalizing already-valid markup. At least according to the <tbody> page:

A <tbody> element's start tag can be omitted if the first thing inside the <tbody> element is a <tr> element, and if the element is not immediately preceded by a <tbody>, <thead>, or <tfoot> element whose end tag has been omitted. (It can't be omitted if the element is empty.) A <tbody> element's end tag can be omitted if the <tbody> element is immediately followed by a <tbody> or <tfoot> element, or if there is no more content in the parent element.

If the markup is valid, why shouldn't it be used?

[rschristian]

If the markup is valid, why shouldn't it be used?

As explained in the above issue, I'd hardly call it "valid" -- it will never exist in that form once being passed through the parser. It's a recoverable and documented (though not in MDN) error state. It's as valid as nesting buttons or anchors, putting flow content into a paragraph, etc., which is to say not at all.

For a real-world example, I recently had to help a user debug their CSS which had the following selector: table > tr. They had no idea that this selector would never match their content.

[BrianJDrake]

MDN clearly says that nesting <button> or <a> elements, or putting flow content (other than phrasing content) into a <p> element, is not valid. But it says that putting <tr> directly under <table> is valid (subject to certain conditions being met), as I explained in my comment above. It is not a normalized form of the markup, but that is a separate issue from whether it is valid.

If putting <tr> directly under <table> is indeed invalid, then the <tbody> page (and other relevant pages) need to be updated to reflect that.

Having said that, I agree that regardless of whether it is valid, it is confusing and should not be recommended. MDN should still mention it, just as MDN mentions deprecated attributes, but should also explain why it should not be used.

[rschristian]

It is not a normalized form of the markup, but that is a separate issue from whether it is valid.

If the input does not match the parser output, the input is invalid. It's not complicated.

The HTML parsers are incredibly capable bits of software that can recover from an ungodly number of errors, but knowingly passing input that it'll have to correct is not ever "valid". This isn't normalization, this is fixing incorrect markup. To call it "normalization" implies it's optional, or can exist in a denormalized state, which it isn't and cannot.

MDN should still mention it

MDN does not document parser behavior in any other situation so I fail to see why it should here.

[wbamberg]

It is not a normalized form of the markup, but that is a separate issue from whether it is valid.

If the input does not match the parser output, the input is invalid.

What's valid is determined by the spec: https://html.spec.whatwg.org/multipage/tables.html#the-tr-element, which says:

Contexts in which this element can be used:
As a child of a thead element.
As a child of a tbody element.
As a child of a tfoot element.
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.

What's valid is also what's considered valid by the W3C validator, which does consider a document like this to be valid:

<!DOCTYPE html>

<html lang="en">
  <head>
    <meta charset="utf-8">
    <title>example page</title>
  </head>

  <body>
    <table>
      <tr>
        <td>a</td>
      </tr>
    </table>
  </body>
</html>

[rschristian]

What's valid is determined by the spec: https://html.spec.whatwg.org/multipage/tables.html#the-tr-element, which says:

Reality often disagrees with spec docs, I wouldn't put too much weight behind one, and in reality, <tr> is not able to exist as a child of <table>. This is an invalid state that all current parsers do not allow to exist. Just as you can author <button>foo<button>bar</button></button> and the parser will correct it, so will <table><tr></tr></table> get corrected.

But at this point, I'm tapping out. A conversation on the realities of adherence to spec docs in regards to the web platform isn't a good use of my time. As the title indicates, I think MDN should consider removing information that is not entirely accurate and leading users down incorrect paths.

[wbamberg]

That said, I do think it's worth describing the parser's behavior, to help out people with this issue:

For a real-world example, I recently had to help a user debug their CSS which had the following selector: table > tr. They had no idea that this selector would never match their content.

...as @BrianJDrake says here:

Having said that, I agree that regardless of whether it is valid, it is confusing and should not be recommended.