HTML API: Apply input preprocessing consistently at Tag Processor read boundaries

[sirreal]

Summary

• Apply HTML input preprocessing consistently at Tag Processor read boundaries.
• Normalize source carriage returns in attributes and replace source NULL bytes in exposed attribute and tag names.
• Keep API-supplied values verbatim while preserving lossless raw-span updates.

Testing

• New input-preprocessing and decoder PHPUnit coverage with browser-verified expectations.
• HTML API and html5lib PHPUnit groups and PHPCS pass.
• codex review --base trunk.

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

Use of AI Tools

AI assistance: Yes
Tool(s): Codex
Model(s): GPT-5.5
Used for: PR description cleanup and code review.

---

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]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props jonsurrell.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[sirreal]

This is an issue:

Input HTML (below "␀" === U+0000 NUL byte)

<div␀ attr␀ class='c␀'>

Appears largely preserved via getters (depending on exactly what is used). The actual HTML is more like the following:

<div� attr� class="c�">

Getter functions are inconsistent

$p = WP_HTML_Processor::create_fragment("<div\0 attr\0 class='c\0'>");
$p->next_tag();
echo "get_tag()\n";
print_r(unpack('C*', $p->get_tag()));
echo "\nget_attribute_names_with_prefix()\n";
print_r(unpack('C*', $p->get_attribute_names_with_prefix('')[0] ));
echo "\nget_attribute('class')\n";
print_r(unpack('C*', $p->get_attribute('class')));
echo "\nclass_list()\n";
print_r(unpack('C*', iterator_to_array($p->class_list())[0]));
echo "\nhas_class('c\u{FFFD}')\n";
var_export($p->has_class("c\u{FFFD}"));
echo "\nhas_class('c␀')\n";
var_export($p->has_class("c\x00"));

They're expected to be replaced with U+FFFD replacement.

get_tag()
Array
(
    [1] => 68
    [2] => 73
    [3] => 86
    [4] => 0
)

get_attribute_names_with_prefix()
Array
(
    [1] => 97
    [2] => 116
    [3] => 116
    [4] => 114
    [5] => 0
)

get_attribute('class')
Array
(
    [1] => 99
    [2] => 0
)

class_list()
Array
(
    [1] => 99
    [2] => 239
    [3] => 191
    [4] => 189
)

has_class('c�')
true
has_class('c␀')
false

[sirreal]

This is relevant around \r U+000D CARRIAGE RETURN has some normalization rules in pre-processing, but can be present as an HTML character reference where it is not removed in pre-processing.

For example (␍ === U+000D CR byte, ␊ === U+000A LINE FEED byte):

<hr attr="&#x0D;&#x0A;"><hr attr="␍␊">

This reports the tree

├─HR attr="␍␊"
└─HR attr="␍␊"

But the expected tree is:

├─HR attr="␍␊"
└─HR attr="␊"

The ␍␊ byte sequence should become to a single ␊, while the character references 
 are literally ␍␊ in the decoded attribute value.

See #42