HTML API: Plans for 6.6

[dmsnell]

HTML issues | Refactors | ↑ Broader Roadmap | ← Plans for 6.5 | → Plans for 6.7

⚠️ Note: This planning document has been abandoned in favor of the Plans for 6.6 issue.

Tasks

• HTML API: Implement active format reconstruction dmsnell/wordpress-develop#13
• HTML API: Improve implementation of adoption agency algorithm dmsnell/wordpress-develop#14

Bug fixes and quality

Continue adding support for more HTML tags

• Support TEMPLATE
• Support TABLE
  • HTML API: Add table support wordpress-develop#6040
• Support forms
• Support foreign elements
  • HTML API: Introduce safe HTML templating. wordpress-develop#5949
  • HTML API: Handle parsing changes in foreign content. wordpress-develop#6006
  • Figure out what to do about CDATA sections
    • We can resolve these by reaching into the Tag Processor when we enter foreign content.
  • Figure out how to rewrite attribute names and namespaces
  • Support SVG and MathML
    • The challenging part is determine if we're in foreign content. These tags are more or less incidental to that, and so there's no need to explicitly support them.

Add functionality to the HTML API

• HTML Templating
  • HTML API: Introduce safe HTML templating. wordpress-develop#5949
  • HTML API: Introduce WP_HTML::tag() for safely creating HTML. wordpress-develop#5884
• set_inner_html()
• CSS selector interface to query HTML and attributes?

Design work and framework improvements

• Add custom escaping and un-escaping functions to avoid improper decoding.
  • PHP's html_entity_decode() is unaware of the ambiguous ampersand and its function signature doesn't leave room to account for it.
  • PHP and WordPress both fail to decode the subset of named character references which don't end in a semicolon.
  • PHP runs multiple passes when operating on attribute values, which could be done in a single pass. [Experiment: Run through esc_attr() in a single optimized pass. wordpress-develop#5337]
• Resolve how to represent plain text vs. trusted HTML vs. user-sourced HTML in templating and in set_inner_html().
• Figure out retroactive changes to the document:
  • Figure out how to handle implicitly-created tags, such as ones creating during active formatting reconstruction, or when encountering an unexpected closing P tag.
  • Figure out how to communicate that the document changed before the current position, as when active format reconstruction, adoption, and fostering occur.
  • Current thinking is that we can allow developers to indicate if they are concerned about retroactive changes to the document, and if so, which elements or situations they care about.
  • For example, someone may not care if the BODY element gains new attributes, or if an empty P element was created, but they may want to know if text was moved from inside a TABLE to before it. This could be the case for code that renders the text of an HTML page; since fostering can re-order text content, it would want to ensure it knows the proper ordering.

Follow-up work to shepherd HTML API usage in Core