HTML API: Update processing instruction parsing

[jonsurrell]

​Processing instruction parsing has been updated in the HTML standard. <?processing instructions ?> were transformed into comments, but are now preserved.

​See the processing instruction states in the standard.

See #65581 (adds updated tests).

​Processing instruction parsing has been updated in the HTML standard. <?processing instructions ?> were transformed into comments, but are now preserved.

​See the processing instruction states in the standard.

See #12423 (merged here) for the test addition..

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

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude
Model(s): Fable 5
Used for: Initial implementation.

This adds PI handling to all the relevant insertion modes. PI handling is notably missing from two places:

• ​in head noscript
• ​in template

This change currently follows the spec for _in head noscript_ but inserts the token _in template_.

It's unclear whether these are an oversight or not. I've asked and will follow-up.

[jonsurrell]

In 62687:

HTML API: Add HTML processing instruction support.

The HTML specification was updated to include _processing instructions_ like <?wp-processing-instruction ...data?>. Implement processing instruction support in the HTML API.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/12424.

Props jonsurrell, dmsnell, westonruter.
Fixes #65582. See #65581.

[jonsurrell]

​Reopening for an adjustment to the updated specification.

The HTML spec updates to introduce HTML processing instructions (PI) overlooked a few insertion modes. PI were added to those modes in ​https://github.com/whatwg/html/pull/12653. Update the HTML API accordingly.

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

Follow-up to: r62687.

[jonsurrell]

In 62714:

HTML API: Handle processing instructions in head noscript.

Processing instructions were omitted from a few insertion modes when they were introduced to the HTML standard. That oversight has since been corrected in the standard; update the HTML API to match.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/12501.

Follow-up to [62687].

Props jonsurrell.
Fixes #65582.

[dmsnell]

Looks like the detection of whitespace after the PI target name should have been a construction with strspn() instead of strpos()

- false !== strpos( " \t\f\r\n?>", $html[ $target_at + $target_length ] )
+ 1 !== strspn( $html, " \t\f\r\n?>", $target_at + $target_length, 1 )

We should fix this before the release.

[jonsurrell]

There was a recent change in r62964, it's now str_contains().

I've reviewed and don't believe there's any issue with the implementation right now. Is this a code style or performance suggestion?

(Note that the change would need to be 1 === strspn(…))

[dmsnell]

@jonsurrell it’s a correctness question. am I misunderstanding, or is the code as-written requiring that a PI node terminate in exactly a space then a tab then a form-feed then a carriage-return then a newline then a ? then a >?

I would expect this to find zero PI nodes. my conjecture, even further muddled by the WPCS change in r62964, is that we want the node to terminate when it ends in any of the whitespace characters then ?>

[jonsurrell]

is the code as-written requiring that a PI node terminate in exactly a space then a tab then a form-feed then a carriage-return then a newline then a ? then a >?

No, that's not the condition as implemented.

​The line is:

str_contains( " \t\f\r\n?>", $html[ $target_at + $target_length ] )

The signature is:

function str_contains(string $haystack, string $needle): bool

So it's checking for a single source byte ($needle) in the list of valid characters $haystack (" \t\f\r\n?>").

The function is often used the other way around, where the $needle is a string literal and the $haystack is arbitrary text.

This could be changed to use strspn(), which may better align with expectations and other patterns in this file, but I don't think it's incorrect as is and there's a good amount of test coverage. If it were trying to match " \t\f\r\n?>" in the HTML input, I'd expect a lot of test failures.

we want the node to terminate when it ends in any of the whitespace characters then ?>

For a valid PI, the target must be follow by ANY of whitespace OR ? OR >.

[dmsnell]

perfect @jonsurrell — glad I misread that. thanks for looking (though it wasn’t super urgent! 😉)