Processing Instruction: Serialize with "?>" close

[sirreal]

Processing Instructions are currently serialized as "<?" + target + " " + data + ">":

Append "<?" (U+003C LESS-THAN SIGN, U+003F QUESTION MARK), followed by the value of current node's target IDL attribute, followed by a single U+0020 SPACE character, followed by the value of current node's data, followed by a single U+003E GREATER-THAN SIGN character (>).

If serialized in this way, data ending in ? would result in different data on next parse:

<?pi ??><!-- target: "pi"; data: "?" -->
<!-- serializes to: -->
<?pi ?><!-- target: "pi"; data: "" -->

This is resolved be serializing with a final ?> instead of >. This should preserve arbitrary PI data correctly. This idea was already considered: #12118 (comment)

Benefits:

• It aligns with existing XML processing instructions and expectations.
• Avoids an edge case with PI data.

Drawbacks:

• An extra character that's redundant in most cases.

See related tests: web-platform-tests/wpt#57486

• At least two implementers are interested (and none opposed):
  • WebKit
  • Chromium
• Tests are written and can be reviewed and commented upon at:
  • Test serialization of processing instructions in HTML web-platform-tests/wpt#57486
• Implementation bugs are filed:
  • N/A
• Corresponding HTML AAM & ARIA in HTML issues & PRs: N/A
• MDN issue is filed: N/A
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/dynamic-markup-insertion.html ( diff )
/infrastructure.html ( diff )
/parsing.html ( diff )

[sirreal]

I've done a quick survey of some major browsers using the following:

const doc = document.createDocumentFragment();
doc.append( document.createElement( 'p' ) );
doc.firstChild.append( document.createProcessingInstruction( 't', 'd' ) );
doc.firstChild.outerHTML

• Chrome 150: <p><?t d?></p>
• Firefox 152: <p><?t d></p>
• Safari 26.5: <p><?t d?></p>

[annevk]

This seems like a change we should make. We don't want <?test ??????> to slowly lose all the question marks through dances of parsing and serialization.

[annevk]

Maybe we can take this opportunity to clean this up a bit. For strings we don't have to state the code points afterwards.

Instead of referencing the IDL attribute we want to reference https://dom.spec.whatwg.org/#concept-pi-target.

We don't have to say U+0020 SPACE character. We can just say U+0020 SPACE.

[sirreal]

I updated the DOM reference for PI target. There was an existing example I reused from elsewhere.

---

The section was inconsistent and needlessly verbose, especially compared with the preceding shadow host rules that exclusively uses quoted strings instead of mentioning Unicode codepoints. I've preferred the string form every except for isolated U+0020 SPACE.

The change is more involved, but I think the result is cleaner, clearer, and more consistent. The resulting DocumentType serialization seems particularly improved:

-Append "<!DOCTYPE" (U+003C LESS-THAN SIGN, U+0021 EXCLAMATION MARK, U+0044 LATIN CAPITAL LETTER D, U+004F LATIN CAPITAL LETTER O, U+0043 LATIN CAPITAL LETTER C, U+0054 LATIN CAPITAL LETTER T, U+0059 LATIN CAPITAL LETTER Y, U+0050 LATIN CAPITAL LETTER P, U+0045 LATIN CAPITAL LETTER E), followed by a space (U+0020 SPACE), followed by the value of current node's name, followed by ">" (U+003E GREATER-THAN SIGN).
+Append "<!DOCTYPE ", followed by the value of current node's name, and "?>".

[sirreal]

I notice one related point in the DOM features section. PI interface and PI target are listed separatedly, while other interfaces are on the same bullet point. Shall I combine them?

• Document interface and its doctype attribute
• ProcessingInstruction interface
• …
• processing instruction target

This could be:

• ProcessingInstruction interface and its target attribute

[annevk]

Thanks, this made me realize we had the wrong link (also in another place). Fixed.

[noamr]

Yea the arguments here are good. Consider blink interested.

[annevk]

Thanks!

[annevk]

@foolip can you update your test PR to match this change?

[foolip]

I've updated web-platform-tests/wpt#57486 to match now.