HTML Templating

STATUS.md

@@ -0,0 +1,118 @@
+## Critical Analysis: WP_HTML_Template vs. Ticket #60229 Requirements
+
+I've examined ticket #60229, the current branch implementation, and the test suite. Here's my analysis:
+
+---
+
+### What's Working Well
+
+**1. Core Safety Goal Achieved**
+The implementation delivers on the primary promise: context-aware auto-escaping. The code correctly escapes `&`, `<`, `>`, `"`, `'` in both text and attribute contexts. Tests confirm placeholders can't be injected via replacement values (non-recursive replacement).
+
+**2. Funky Comment Syntax**
+The `</%placeholder>` syntax is a smart choice—it's valid HTML (parsed as a funky comment), can't be nested by construction, and is visually distinctive. The parsing handles whitespace around names correctly.
+
+**3. Nested Templates**
+Template composition (`WP_HTML_Template` as replacement value) works for text context with proper escaping propagation. The rejection of templates in attribute context is the right safety call.
+
+**4. Compile-once Design**
+Lazy compilation with cached edits (`$edits` array) is efficient for template reuse.
+
+**5. Boolean Attribute Support**
+Supply `true` to create a boolean attribute (`disabled="</%d>"` + `true` → `disabled`), or `false`/`null` to remove an attribute entirely. Only works for whole-attribute placeholders—partial placeholders reject boolean values.
+
+---
+
+### What's Missing from the Ticket Requirements
+
+**1. No URL Escaping (Ticket TODO)**
+The ticket explicitly says "does not escape URLs differently than other attributes." The XSS test shows `javascript:alert("xss")` only escapes quotes—no `esc_url()` equivalent. This is a security gap for `href`/`src` attributes.
+
+**2. No Attribute Spread**
+Ticket comment 9 discusses "spread" attributes for making tags placeholders. Not implemented.
+
+**3. Missing Output Format Methods**
+Ticket TODO lists `->final_output_to_browser()`, `->final_output_to_plaintext()`, `->final_output_to_markdown()`, etc. None exist.
+
+**4. Embed Replacement in Tag Processor (Ticket TODO)**
+The ticket wants replacement embedded in the Tag Processor. Current implementation uses a separate class with its own parsing pass.
+
+---
+
+### Overlooked Issues in the Ticket
+
+**1. RAWTEXT/RCDATA Element Handling Is Half-Baked**
+Tests show placeholders inside `<script>`, `<style>` are preserved literally, while `<title>`, `<textarea>` escape them as text. Neither allows actual replacement. The ticket doesn't acknowledge this limitation clearly. If I write a template for a script tag's content, I'd expect placeholders to work.
+
+**2. Table Context Parsing**
+Test explicitly skipped: "IN TABLE templates are not supported yet." HTML parsing rules for tables are complex—implicit elements, foster parenting. The ticket doesn't address this at all. Tables are everywhere in WordPress admin.
+
+**3. No i18n Integration**
+The ticket mentions "translation" as a sigil use case, and gziolo's comment asks about `createInterpolateElement` parity. Zero implementation of translation awareness. For WordPress core, this is a big miss.
+
+**4. Performance Not Benchmarked**
+Normalization runs twice: once in `compile()` for text detection, once in `render()` for final output. For high-frequency template rendering (e.g., list items), this could add up.
+
+**5. Error Handling Philosophy Unclear**
+`render()` returns `false` on errors, but `bind()` uses `_doing_it_wrong()` warnings and still returns a template. Mixed signals—should errors be fatal or recoverable? The test gaps document lists many untested failure cases.
+
+---
+
+### Gaps in Test Coverage (From Test-Gaps.md + My Observations)
+
+**High Priority Missing:**
+
+-   ~~Non-string replacement values (integers, arrays, nulls) → should fail gracefully~~ ✅ Tests exist
+-   ~~Multiple placeholders in single attribute (e.g., `href="</%scheme>://</%host>"`)~~ ✅ Works, tests added
+-   Template immutability verification (`bind()` returns new instance)
+
+**The PRE newline test is skipped** but the behavior matters—WordPress often outputs preformatted code.
+
+**No tests for:**
+
+-   Very long templates/replacements (memory/performance)
+-   Deeply nested templates (stack depth)
+-   Unicode/multibyte characters in placeholder names
+-   SVG/MathML elements
+
+---
+
+### API Design Questions
+
+**1. Why `from()` → `bind()` → `render()` instead of a single call?**
+For reusable templates, the separation makes sense. But most WordPress use cases are one-shot renders. A convenience method like `::render($template, $replacements)` would be more ergonomic.
+
+**2. `render()` Returns `string|false`—Is That Right?**
+Returning `false` on error is classic WordPress, but it means every call site needs error checking. Exceptions or a Result type would be safer, though breaking with WP conventions.
+
+**3. What About Streaming/Chunked Output?**
+For large templates, building the entire string in memory before output is wasteful. No consideration of echo-as-you-go.
+
+---
+
+### What's the Competition Doing That WP Isn't?
+
+-   **Blade/Twig**: Rich conditionals, loops, inheritance. WP_HTML_Template is deliberately minimal.
+-   **htmx/alpine patterns**: Server-side templating with client-side enhancement. No thought given here.
+-   **Lit/React SSR**: Hydration markers. Not applicable, but WP could learn from structured output strategies.
+
+The ticket's philosophy is "prefer trust and safety over features"—valid, but means this won't replace most template use cases. It's targeted at safe HTML generation, not a full templating language.
+
+---
+
+### Summary Table
+
+| Requirement                | Status | Notes                              |
+| -------------------------- | ------ | ---------------------------------- |
+| Context-aware escaping     | ✅     | Works for text and attributes      |
+| Funky comment placeholders | ✅     | Clean implementation               |
+| Nested HTML via Templates  | ✅     | Text context only                  |
+| Boolean attributes         | ✅     | true/false/null for whole-attr     |
+| URL escaping               | ❌     | Only generic escaping              |
+| Attribute spread           | ❌     | Not implemented                    |
+| Output format methods      | ❌     | Not implemented                    |
+| Tag Processor integration  | ❌     | Separate class                     |
+| Table context support      | ❌     | Explicitly unsupported             |
+| i18n integration           | ❌     | Not addressed                      |
+| RAWTEXT/RCDATA replacement | ❌     | Placeholders don't work inside     |
+

src/wp-includes/html-api/class-wp-html-tag-processor.php

@@ -708,7 +708,7 @@ class WP_HTML_Tag_Processor {
 	 * @since 6.2.0
 	 * @var WP_HTML_Attribute_Token[]
 	 */
-	private $attributes = array();
+	protected $attributes = array();
 
 	/**
 	 * Tracks spans of duplicate attributes on a given tag, used for removing