Found while fixing #342 (#481), which leaves this unchanged.
A browser inserts a form start tag that arrives directly inside a table and pops it at once, so nothing that follows is inside the form. The tag balancer keeps the form open as an ordinary container, so the text and rows after it nest inside it, and a browser reads the output as a different tree:
<table><form>x<tr><td>y</td></tr></table>
now: <table><form>x<table><tbody><tr><td>y</td></tr></tbody></table></form></table>
browser reads the output as: x<table><form></form></table><table><tbody><tr><td>y</td></tr></tbody></table>
browser reads the input as: x<table><form></form><tbody><tr><td>y</td></tr></tbody></table>
The element tables say a table can contain a form, which is true of the tree a browser builds, but the browser's "form element pointer" handling means the form has no content there. A fix would treat a form opened directly in a table, row group or row as closed immediately, the way #481 treats a void element. Layout rather than safety. Reproduced on main at fad01c1.
Found while fixing #342 (#481), which leaves this unchanged.
A browser inserts a
formstart tag that arrives directly inside a table and pops it at once, so nothing that follows is inside the form. The tag balancer keeps theformopen as an ordinary container, so the text and rows after it nest inside it, and a browser reads the output as a different tree:The element tables say a table can contain a
form, which is true of the tree a browser builds, but the browser's "form element pointer" handling means the form has no content there. A fix would treat aformopened directly in a table, row group or row as closed immediately, the way #481 treats a void element. Layout rather than safety. Reproduced onmainat fad01c1.