I'm okay with it throwing an error for this case. Is there some benefit to developers to letting it quietly create invalid markup?

Well, to be clearer, while it always crashes it only *sometimes* creates invalid markup. I ran into the bug because I am using a templating library that recursively copies child elements into (a copy of) the parent element. The bug was triggered when the templating engine was copying a template containing

<table>     <tbody><tr>stuff...</table>

. The first child the templating engine tried to copy into a new table node was the textnode consisting of just whitespace before the tbody. Creating (temporarily) <table>..whitespace..</table> is, I think, a plausible step in building a table. If jq continues to throw this error, then it becomes the responsibility of the template engine to check for and skip inserting whitespace, which just doesn't seem like a job it should have to do given that it is building valid html.

Ideally do not throw an exception and add the text content like jQuery 1.9 and older versions.

Possible fix is:

function manipulationTarget( elem, content ) {
   return jQuery.nodeName( elem, "table" ) &&
-    jQuery.nodeName( content.nodeType === 1 ? content : content.firstChild, "tr" ) ?
+    jQuery.nodeName( ( content.nodeType === 1 || content.firstChild === null ) ? content : content.firstChild, "tr" )

Sorry, what I was asking is, other than not throwing an error, what should the outcome be? You're defining a behavior with your suggested patch but is that really the desired behavior?

Replying to [comment:4 dmethvin]:

Sorry, what I was asking is, other than not throwing an error, what should the outcome be? You're defining a behavior with your suggested patch but is that really the desired behavior?

So at the risk of overgeneralizing, I think we should recognize that it is possible (and natural) for invalid html to "grow" to become valid. This implies that jquery should be robust in handling (temporarily) invalid html, in order to protect the user from having to maintain validity at every single step.

Another, related example of this would be manipulating a table without a tbody. jquery appears to helpfully create a tbody in this case. But what happens if the table is only temporarily without a tbody, and the user adds one later? Suddenly we have two tbodys, which is a problem.

So at the risk of overgeneralizing, I think we should recognize that it is possible (and natural) for invalid html to "grow" to become valid. This implies that jquery should be robust in handling (temporarily) invalid html, in order to protect the user from having to maintain validity at every single step.

It can be risky to define our behavior as a superset of the standard. If the standard changes against jQuery's behavior, we're forced to choose between standards and backwards compatibility.

The pull request, only ensures that there is one child element in the table and (implicitly) that no exception was thrown. I think that is good, actually, because it doesn't put too many constraints on how a browser could handle invalid markup. But what if the browser discarded the text? I haven't looked at the requirements for how HTML5 would parse this but I wouldn't want to go beyond (and certainly not against) that.

Another, related example of this would be manipulating a table without a tbody. jquery appears to helpfully create a tbody in this case.

That is required because IE auto-inserts a tbody if we don't. It is easier to make all browsers behave consistently that way. I don't think this case is analogous.

But what happens if the table is only temporarily without a tbody, and the user adds one later? Suddenly we have two tbodys, which is a problem.

A table can have multiple tbody elements. http://dev.w3.org/html5/html-author/#the-table-element

Fix #14290. Don't throw if text node is appended to table. Close gh-1371.

Changeset: ec3ac9a247ec3132dea3c30ca36cefc217e25441