Open karger opened 11 months ago
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.
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?
What is the general rule here? Any descendant mv-list-item
?
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.
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.
https://codepen.io/karger/pen/ZEwRzEd?editors=1100