HTML API: Update Processing Instruction handling#12424
Conversation
…essing-instruction-parse
…oken fixtures Claude-Session: https://claude.ai/code/session_019T4FGdVaBpVbMRcBbQPehd
…essing-instruction-parse
The HTML standard has added Processing Instruction parsing. The HTML API needs updates to handle PI.
…essing-instruction-parse
Test using WordPress PlaygroundThe 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
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
| case '#comment': | ||
| case '#funky-comment': | ||
| case '#presumptuous-tag': | ||
| case '#processing-instruction': |
There was a problem hiding this comment.
We'll assume this is the intention. This entire insertion mode is gone from the current version of the spec: #9298
|
This adds PI handling to all the relevant insertion modes. PI handling is notably missing from two places: 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. |
PI nodes exist and are parsed. Bogus comments are just bugos comments.
| /** | ||
| * Processing instructions are serialized as `<?target data>`, not `<?target data?>`. | ||
| * Both forms are parsed equivalently. | ||
| * | ||
| * @see https://html.spec.whatwg.org/multipage/parsing.html#serialising-html-fragments | ||
| */ | ||
| case '#processing-instruction': | ||
| /** | ||
| * A final `?` is ignored when parsing a processing instruction. If the data ends | ||
| * with `?`, it must be doubled to ensure its recognized as part of the data and | ||
| * not the closing `?>` sequence. | ||
| */ | ||
| $data = $this->get_modifiable_text(); | ||
| if ( str_ends_with( $data, '?' ) ) { | ||
| $data .= '?'; | ||
| } | ||
| $html .= "<?{$this->get_tag()} {$data}>"; | ||
| break; |
|
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 Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
| * parsing: data with leading whitespace cannot be represented. | ||
| */ | ||
| if ( 0 !== strspn( $plaintext_content, " \t\f\r\n" ) ) { | ||
| return false; |
There was a problem hiding this comment.
Q? would it be pragmatic to trim this and call _doing_it_wrong()?
| ? '?>' | ||
| : '>'; | ||
|
|
||
| $this->lexical_updates['modifiable text closer'] = new WP_HTML_Text_Replacement( $token_end, 0, $closer ); |
There was a problem hiding this comment.
how about just a single update, the existing modifiable_text, and update get_modifiable_text() accordingly?
| * Processing instructions with an allowable target are parsed | ||
| * into processing instruction nodes. The reserved `xml` and | ||
| * `xml-stylesheet` targets, and targets with characters outside | ||
| * an ASCII-representable subset, are turned into bogus comments. |
There was a problem hiding this comment.
this is another case for preserving PI_NODE_LOOKALIKE
| * `COMMENT_AS_INVALID_HTML`. | ||
| * | ||
| * @since 6.5.0 | ||
| * @deprecated 7.1.0 Use `COMMENT_AS_INVALID_HTML` instead. |
There was a problem hiding this comment.
why not preserve the extra lexical info that PI_NODE_LOOKALIKE provided? many a DSL are formed from these
…ocessing-instruction-parse
Replace the three coordinated replacements (separator, data, closer) with one replacement spanning from the start of the data through the end of the token, holding the raw syntax for that region. This removes the dependency on update ordering at shared offsets and the named-key lifecycle for the auxiliary replacements. The enqueued text is raw syntax rather than the data itself, so get_modifiable_text() now finds the data within a pending update by applying the same rules used when parsing the document. Claude-Session: https://claude.ai/code/session_01NKkom28VKTXSqDTDq5g3yS
Bogus comments of the form `<?target ... ?>` whose targets are not allowed in HTML processing instructions - the reserved `xml` and `xml-stylesheet` names and XML-valid names with characters like `:` and `.` - are again classified as COMMENT_AS_PI_NODE_LOOKALIKE, with the target exposed through get_tag() and the browser-visible text through get_full_comment_text(). Removes the deprecation of COMMENT_AS_PI_NODE_LOOKALIKE: valid processing instructions produce their own token type, but PI-like bogus comments remain distinguishable from other invalid HTML. Claude-Session: https://claude.ai/code/session_01NKkom28VKTXSqDTDq5g3yS
Serialization and modifiable text updates now always terminate a processing instruction with the explicit `?>` closer instead of preserving or emitting the bare `>` form. The closer's `?` is dropped when parsing, so this single form represents any data unambiguously - data ending in `?` no longer needs special doubling logic in the serializer, and the modifiable text setter no longer chooses between closer forms. The HTML fragment serialization algorithm specifies the `<?target data>` form, which cannot represent data ending in `?`. Claude-Session: https://claude.ai/code/session_01NKkom28VKTXSqDTDq5g3yS
The HTML Standard is being updated to serialize processing instructions with the `?>` closer, matching this serializer. Claude-Session: https://claude.ai/code/session_01NKkom28VKTXSqDTDq5g3yS
Handle Processing Instructions in the HTML API.
Some doubts about parsing PI in some insertions modes came up while implementing this change. I've raised them with the standards:
See #12423 (merged here) for the test addition.(landed in r62655)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 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.