Non mv-list-item children (<tr>s) get replicated when the mv-list is a <table>

[karger]

https://codepen.io/karger/pen/ZEwRzEd?editors=1100

[LeaVerou]

Yeah, this is because the proper table structure assumes a <tbody>, and if you don't add that, the browser does. So by the time Mavo sees the structure of your HTML, it sees:

<div mv-app="appName" mv-mode="edit">
	Static trs are being replicated, as well as the "add item" buttons!
	<table mv-list="stuff" mv-initial-items="2">
		<tbody>
			<tr>
				<td>First</td>
				<td>Second</td>
			</tr>
			<tr mv-list-item>
				<td property="first"></td>
				<td property="second"></td>
			</tr>
			<tr>
				<td>First Footer</td>
				<td>Second Footer</td>
			</tr>
		</tbody>
	</table>
</div>

So it assumes the <tbody> is the item of the stuff list, and then you have an orphan mv-list-item. It tries to turn the latter into a list as well, by wrapping it with another <tbody>.

I'm tending to mark this as WONTFIX since there's no way to fix it — the original HTML structure cannot be recovered.

[karger]

But, the original mv-list-item is still present, now as a grandchild of the mv-list. So why not have mavo replicate the grandchild?

[LeaVerou]

What is the general rule here? Any descendant mv-list-item?

[karger]

I would say any uninterrupted descendant---if there's an intervening mv-list then of course that should take precedence. Put another way mv-list-item should tie to the closest mv-list ancestor.

[LeaVerou]

If creating lists with just mv-list or just mv-list-item becomes commonplace (rather than just error recovery), I don't think we can assume that was the author's intent.