HTML API: Add table support

[sirreal]

Trac ticket: Core-61576

Add support for table elements:

• TABLE
• THEAD, TBODY, TFOOT
• TR
• TD, TH
• COL, COLGROUP
• CAPTION

Not all necessary insertion modes are implemented in this PR, so e.g. "in caption" and "in select in table" modes are not implemented in this PR.

HTML5-lib test change (./vendor/bin/phpunit --group html-api-html5lib-tests):

-Tests: 610, Assertions: 275, Skipped: 335.
+Tests: 610, Assertions: 301, Skipped: 309.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[dmsnell]

just curious about this, because these elements are implicitly created on +TABLE, so I think the only case we could get here is with a TEMPLATE

<table>
<td><template>This </table> does not close the outer one</template>
</table>

[sirreal]

This is just following the spec (quoted below). I'm reluctant to deviate from the spec in all but the most obvious places. There are many places the switch modes and reprocess tokens or process tokens following the rules for other modes.

A character token, if the current node is table, tbody, template, tfoot, thead, or tr element
Let the pending table character tokens be an empty list of tokens.

Let the original insertion mode be the current insertion mode.

Switch the insertion mode to "in table text" and reprocess the token.

[dmsnell]

there was no hint of asking you to deviate from the spec; all I was doing was observing an interesting oddity since the only elements we're checking are ones that should always be open. I think that TEMPLATE is the only exception. this was just exploring the rules.

if this turns out to be true, it might be possible one day to verify and take advantage of. for now, all it did was seem odd when I saw it, and then I realized there's an escape hatch in almost all of these situations - the TEMPLATE element.

[dmsnell]

@sirreal I fixed two logic issues:

• in IN CELL we have to check if the current node has the same name as the matched token, but we were only checking that it had a name at all.
• in IN TABLE BODY for -TBODY, … we needed to clear to table body context.

After our short discussion about it I went ahead with insert_virtual_node() because I want that to have a bookmark, and I think it might be important later to add things like namespace and whether it's virtual.

I've made comment and other minor changes, which can all be reverted if you think it's best as it was before.

[dmsnell]

Interestingly, @sirreal, this is no longer required, since we moved to processing the event queue. I'm leaving it in for now, though, while pondering the later change which avoids immediately popping the FORM off the stack of open elements.

[dmsnell]

This is where I'm pondering.

[sirreal]

What's the motivation for doing it this way instead of adding and popping right here?

[sirreal]

There's an error in the new form test with the change to auto-close the form where the form closer is not visited by next_token. It's fixed with this patch, although I haven't investigated why:

diff --git before/src/wp-includes/html-api/class-wp-html-processor.php after/src/wp-includes/html-api/class-wp-html-processor.php
index 1e6a18389b..0d1c7c1496 100644
--- before/src/wp-includes/html-api/class-wp-html-processor.php
+++ after/src/wp-includes/html-api/class-wp-html-processor.php
@@ -2356,10 +2356,9 @@ class WP_HTML_Processor extends WP_HTML_Tag_Processor {
 				}
 
 				// This FORM is special because it immediately closes and cannot have other children.
-				$this->state->current_token->has_self_closing_flag = true;
-
 				$this->insert_html_element( $this->state->current_token );
 				$this->state->form_element = $this->state->current_token;
+				$this->state->stack_of_open_elements->pop();
 				return true;
 		}
 

I'll push that change and tests should be passing again. It's effectively reverting part of your updates so happy to discuss further.

[sirreal]

@dmsnell The changes you've pushed look good, thanks for catching a couple of bugs and I do like the method for creating virtual nodes.

The last remaining thing is to sort out the FORM element in table insertion mode that's immediately popped.

[dmsnell]

I'll push that change and tests should be passing again. It's effectively reverting part of your updates so happy to discuss further.

I was considering this because I wanted the code to function as the void tags function, but I can't figure out what's wrong. Along the way I found some bugs in next_token() I introduced when fixing breadcrumbs, but the fix is incoming and easy. We don't close out the remaining open stack elements at the end of the document because they never get popped.

[dmsnell]

Merged in [58806]
5351cd2