HTML API: Plans for 6.9

[dmsnell]

🔝Block API | HTML issues | Refactors | ↑ Broader Roadmap | ← Plans for 6.7

HTML rule changes.

• Relax <select> parser whatwg/html#10557
  • HTML API: Update customizable <select> parsing wordpress-develop#9298

Trac tickets.

• Core-63694: Improvements to HTML handling in Core.
• Core-63738: Improvements to the HTML API itself.

Core improvements in handling HTML

• HTML API: Refactor wp_kses_hair() wordpress-develop#9248
• HTML API: Reliably parse HTML in wp_html_split(). wordpress-develop#9270
• HTML API: Reliably parse HTML in wp_strip_all_tags(). wordpress-develop#9271
  • This work probably won’t make it in due to deeper coupling between the use of wp_strip_all_tags() and CSS content, which is not HTML and actually will be corrupted if treated as such.
• HTML API: Reliably parse HTML in get_url_in_content() wordpress-develop#9272

Improvements to the HTML API

• HTML API: Update customizable <select> parsing wordpress-develop#9298
• Add private annotation to the WP_HTML_Doctype_Info class wordpress-develop#9301

Performance

• Convert bookmark names to numeric indices in a linear array to avoid the overhead of string hashing.
• HTML API: Reduce skip_script_data length checks wordpress-develop#9230
• HTML API: Simplify META tag encoding processing wordpress-develop#9231

Feature-set

• Potentially some movement towards inner_html functionality.

Block Scanner

• Blocks: Introduce WP_Block_Processor for efficiently parsing blocks. wordpress-develop#9105
  • Based on the HTML API design, a memory-efficient method for scanning through a document and inferring block structure.

---

The rest of this section is likely not going to make it into 6.9 but it retained for continuity and tracking purposes.

Lingering work from 6.7

⚠️ The tasks in this section likely won’t make it into 6.9 due to pausing of Core work in early 2025. While it could still make it, as the roadmap is revisited other priorities may take place.

• Speed speed speed. Make the HTML Processor 10x faster.

  • Can we defer parsing and deduplicating attribute names while parsing tags and only start doing that when reading attributes?
    • Potentially around a 3% speed improvement in scanning tokens with the Tag Processor when not interacting with attributes.
  • Remove all if statements that don't execute anything (they have a comment as their body).
  • If 6.7 includes full support for all HTML tags, measure the impact of reordering the case statements in each insertion mode. Test against 100s of 1000s of websites based on web popularity.
  • Profile the parsing of 100s of 1000s of websites and see if anything surprising pops up in the results.
  • Replace '#text' === $token_type with ::STATE_TEXT_NODE === $this->parser_state
  • Eagerly set token name, type in step() where all nodes are real. Reference these values instead of calling ->get_token_name() etc…
  • Remove after_element_push() since these are all instigated from within the HTML Processor, unlike pop with pop_until() (unless we made pop_until() return a generator and we could foreach ( $state->pop_until( 'TAG' ) as $popped )
  • Flagification
    • Replace as many repetitive if checks with flags that are set on events, as is done with has_p_in_button_scope.
    • Indicate once in next_token() if a text node is only whitespace.

• Following the change to push/pop, immediately pop elements off of the stack of elements as instructed in the parsing rules, vs. letting step() perform the check and pop.

With some initial explorations I've found 16% - 40% speed improvement with some of these ideas. That's not good enough, but it's a start.

Lingering support edge-cases.

• HTML API: Handle content after BODY, HTML where possible wordpress-develop#7312
• HTML API: Implement active format reconstruction wordpress-develop#6982 and HTML API: Active format reconstruction with noah's ark dmsnell/wordpress-develop#19
• HTML API: Improve implementation of adoption agency algorithm wordpress-develop#6983
• Audit all seek() calls in the HTML Processor to ensure reliability. (Core-????)
  May be covered by HTML API: Ensure that full processor can seek to earlier bookmarks.
  • Ensure that internal state isn't messed up:
    • breadcrumbs
    • FORM pointer
    • HEAD pointer
    • virtual nodes
    • list of active formatting elements
    • "strip last newline at" pointers

New Features and Interfaces

• Introduce safe composable HTML templating.
• Inner and outer HTML support. (Core-????)
  • WIP: HTML API: Add set_inner_html() to HTML Processor wordpress-develop#7326
  • HTML API: Add method to create fragment at node wordpress-develop#7348
  • HTML API: Use create_fragment_at_node to allow more contexts in create_fragment wordpress-develop#7777

Blocks

• Continue developing block attribute sourcing.
• Iterate on the Server Directive Processor.
• Iterate on the Block Bindings processor.

[t-hamano]

Let's add this issue to the project board to discuss how far we can tackle tasks in WordPress 6.8.

[kjnanda]

Hello @t-hamano

Could you please confirm the status for this issue for 6.8 release? Are we on track to include this?

[dmsnell]

@kjnanda I’m not sure how much of this will make it into 6.8, if any of it at all.

[t-hamano]

@kjnanda I've added this issue to the project board just in case, but there may not be enough contributors or time to act on it. There has been some discussion in the editor chat about these tracking issues:

https://wordpress.slack.com/archives/C02QB2JS7/p1739354637281219

[kjnanda]

Thanks for the update @dmsnell @t-hamano 🙌🏻

[t-hamano]

This issue has been punted to 6.9. Let's move this issue to the 6.9 Editor Tasks board and see what's possible in 6.9.