HTML API: Add support for H1-H6 elements in the HTML Processor

[dmsnell]

Previously these have been unsupported, but in this patch we're adding support for the tags so that the HTML Processor can process documents containing them.

There was a design discussion about introducing a constant to communicate "any of the H1 - H6 elements" but this posed a number of challenges that don't need to be answered in this patch. For the time being, because the HTML specification treats H1 - H6 specially as a single kind of element, the HTML Processor uses an internal hard-coded string to indicate this. By using a hard-coded string it's possible to avoid introducing a class constant which cannot be made private due to PHP's class design. In the future, this will probably appear as a special constant in a new constant-containing class.

cc: @ockham @jonsurrell @westonruter

Trac Ticket: Core-60060

Adds support for handling H1 - H6 elements in the HTML Processor.

• [x] Verified that these heading elements convey no special rules in other parts of the HTML spec. The definitions within IN BODY processing seem sufficient. For example, there's no mention about special handling in another section about them.
• [x] Write positive-affirming tests for heading element support.

[Bernhard Reiter]

In 57186:

HTML API: Add support for H1-H6 elements in the HTML Processor.

Previously these have been unsupported, but in this patch, support is added for the tags so that the HTML Processor can process documents containing them.

There was a design discussion about introducing a constant to communicate "any of the H1 - H6 elements" but this posed a number of challenges that don't need to be answered in this patch. For the time being, because the HTML specification treats H1 - H6 specially as a single kind of element, the HTML Processor uses an internal hard-coded string to indicate this. By using a hard-coded string it's possible to avoid introducing a class constant which cannot be made private due to PHP's class design. In the future, this will probably appear as a special constant in a new constant-containing class.

Props dmsnell, jonsurrell.
Fixes #60060.

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

[TobiasBg]

This commit introduces a few @TODO: tags in inline documentation.

Following [57077] (and the referenced ​https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/#phpdoc-tags ), these should be replaced by @todo.

(Currently, the two files /wp-includes/html-api/class-wp-html-active-formatting-elements.php and /wp-includes/html-api/class-wp-html-processor.php are the only PHP files in core that have @TODO or @TODO: tags.)

Trac ticket: Core-60060

cc: @tobiasbg

[dmsnell]

@TobiasBg I created ​https://github.com/WordPress/wordpress-develop/pull/5770 to make your requested changes. I'm not sure what happened because I don't think we've been merging over any failed tests in the CI pipeline.

LGTM. Is there any sniff there that check this?

LGTM. Is there any sniff there that check this?

LGTM. Is there any sniff there that check this?

Thanks for the PR. It's not just lowercasing though. The colons should be removed as well.

[Bernhard Reiter]

In 57209:

HTML API: Apply linting changes to @TODO comments.

Lowercase @TODO comments introduced by [57186], and remove spurious colons after them.

Props dmsnell, TobiasBg, mukesh27, sergeybiryukov, jonsurrell.
Fixes #60060.

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

[stevenlinx]

as part of a standalone dev note post