HTML API: Add explicit handling or failure for all tags

[sirreal]

Trac ticket: https://core.trac.wordpress.org/ticket/60092

This implements part of the work described here: WordPress/gutenberg#54579

Abort with "unsupported" for all called-out tag names in the IN BODY section so that we can implement the "Any other start tag" and "Any other end tag" rules, including support for custom elements.

---

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]

@sirreal I've manually reviewed each tag to ensure that it's listed where it should be and missing where it shouldn't. although it doesn't require special handling, I have added in SARCASM so that we can add support for that by itself, perhaps as the last tag for which we add support - I'm sentimental or something.

note that I uncovered failing tests only by implementing the any other tag sections here. we can remove that handling, but given your changes I think it's a nice boost to add them in, and it was hard to review the changes without ensuring that those tags are or aren't properly processed.

I welcome your thoughts on this. thanks for the hard work!

[sirreal]

I uncovered failing tests only by implementing the any other tag sections here

I was worried about that myself, I think it makes sense to add the any other tag handling here as well. I'll review your changes.

[sirreal]

I ran the test suite from #5794 against this and I see we handle ~30 more cases (previously skipped as unsupported). No new errors.

[dmsnell]

@sirreal it looks like something may have gone wrong in the last two commits as this is now changing the .github directory

[sirreal]

Thanks @dmsnell, I removed the offending commits.

[dmsnell]

@sirreal I added the WPCS exclusion for goto statements in here to silence the warning. that came from #5539

[sirreal]

I've updated the title to reflect that we explicitly handle all tags now. Tags that require special handling will fail when unsupported and the "all other tags" rules have been implemented (by @dmsnell).

I reviewed the implementation of the all other tags handling. The opener rule is simple. The closer rule is much more difficult to follow, but I've carefully compared the implementation with the specification and I believe it's correct. I'm also confident in these changes thanks to the tests here and from #5794 which I've also run.

[ockham]

The naming of the function and the variable is slightly misleading now, since IIUC, the newly added elements are still _un_supported, no? 🤔 (They do throw WP_HTML_Unsupported_Exception.)

[sirreal]

This should be the supported tags. If you compare it with data_unsupported_special_in_body_tags from the wpHtmlProcessor suite, there should be no overlap between elements in this array and that array.

Are you sure these tags throw?

A lot of tags move from unsupported to supported in this change because the catch-all "any other tag" rules are implemented here, and only the tags that require (currently unimplemented) special handling remain unsupported.

[dmsnell]

typo: should be DFN

[dmsnell]

@sirreal I've made several changes to this PR

• refactored the closing tag logic and eliminated the goto. I confirmed that it's safe to remove elements from the stack of open elements while walking up.
• added the list of supported tags to the docblock at the start of the class.
• updated comments that will generate linting nags.
• fixed a typo in one of the tests: DEFN was listed but it should have been DFN.

additionally I ran the html5lib test suite against this branch and saw no regressions. the 10 failures relate to the tests not starting in IN BODY context, I believe, and are present in trunk

Tests: 1814, Assertions: 2685, Errors: 1, Failures: 10, Skipped: 802.

I'm a bit concerned that we haven't fully evaluated every branch in the "any other tag" logic; in fact I may try and run coverage on our test suite if I can get that working and make sure.

[dmsnell]

try and run coverage on our test suite if I can get that working and make sure.

good news everybody! I ran the coverage tests and it looks like we have 100% coverage for these changes. we are missing coverage for other parts of IN BODY, so maybe we should target 100% of step_in_body() for 6.5

[dmsnell]

We'll try and get this in next, and then we can target the list elements. I think we can also add BR, HR, and PRE for 6.5 and cover most of all we need.

I'd like your final review of my change to the closing tag logic, but this checks out on all the tests I'm throwing at it.

[sirreal]

I've reviewed the additional changes and they look good to me. Consider this my approval 👍

[ockham]

Committed to Core in https://core.trac.wordpress.org/changeset/57248.