[php-src] Issue #23334: Dom\HTMLTemplateElement is missing, so template contents are unreachable from the DOM API
[email protected] (nicolas-grekas)
| Newsgroups | php.bugs |
|---|---|
| Message-ID | <[email protected]> |
Issue: https://github.com/php/php-src/issues/23334
Author: nicolas-grekas
### Description
`Dom\HTMLDocument` parses `<template>` contents into an internal `DocumentFragment`, which is correct per spec, but there is no `Dom\HTMLTemplateElement` class and no `content` property, so the parsed contents cannot be reached through the DOM API at all. `innerHTML` returns them as a string and serialization round-trips them, but no node inside a template can be obtained.
The empty `childNodes` is correct and I am not reporting it. The missing accessor is the problem.
```php
<?php
$doc = Dom\HTMLDocument::createFromString(
'<!doctype html><body><template><input name="x"></template>',
LIBXML_NOERROR
);
$tpl = $doc->getElementsByTagName('template')->item(0);
var_dump($tpl::class);
var_dump(class_exists('Dom\HTMLTemplateElement'));
var_dump($tpl->childNodes->length); // 0 is correct per spec
var_dump($tpl->innerHTML); // contents are there
var_dump($doc->querySelectorAll('input')->length);
var_dump($tpl->content); // no way to reach them
```
### Actual output
```
string(15) "Dom\HTMLElement"
bool(false)
int(0)
string(16) "<input name="x">"
int(0)
Warning: Undefined property: Dom\HTMLElement::$content
NULL
```
### Expected output
`$tpl` should be a `Dom\HTMLTemplateElement`, and `$tpl->content` should be the `Dom\DocumentFragment` holding `<input name="x">`, so that `$tpl->content->querySelectorAll('input')` returns 1 node.
Per the HTML Standard, [4.12.3 The `template` element](https://html.spec.whatwg.org/multipage/scripting.html#the-template-element):
> Each `template` element has an associated `DocumentFragment` object that is its template contents.
> The template contents of a `template` element are not children of the element itself.
with IDL:
```webidl
interface HTMLTemplateElement : HTMLElement {
readonly attribute DocumentFragment content;
...
};
```
So `content` is the spec-mandated way to reach these nodes, and it is the only one. `childNodes` being empty is correct precisely because `content` is supposed to exist.
### The fragment already exists and is already reachable by accident
The internal fragment is fully built and correctly linked. It can be obtained today if some descendant happens to carry an `id`:
```php
$d = Dom\HTMLDocument::createFromString(
'<!doctype html><body><template id="tpl"><div id="inner">X</div></template>', 0);
$tpl = $d->getElementById('tpl');
$inner = $d->getElementById('inner'); // Dom\HTMLElement DIV
$frag = $inner->parentNode; // Dom\DocumentFragment, nodeType 11
var_dump($frag->parentNode === $tpl); // bool(true)
```
`$frag` supports `childNodes`, `querySelectorAll()`, `textContent` and `saveHtml()` normally. `ext/dom/private_data.h` already stores it in `template_fragments` and already exposes `php_dom_ensure_templated_content()`, so exposing it as a `content` property looks like a small change over existing plumbing.
### Affected versions
Verified identical on 8.4.23 and 8.5.8, and `ext/dom/php_dom.stub.php` on master has neither `HTMLTemplateElement` nor `content`.
### Why it matters
Any consumer that walks the DOM silently sees nothing inside a template: `childNodes`, `firstChild`, `children`, `getElementsByTagName`, `getElementsByClassName`, `querySelectorAll`, `Dom\XPath` (with or without the `html:` prefix bound to `http://www.w3.org/1999/xhtml`) and a full recursive tree walk all return zero results, at any nesting depth. Sanitizers, scrapers, template processors, test-assertion helpers and accessibility linters therefore cannot inspect template contents, and cannot tell an empty template from a full one except by string-matching `innerHTML`. The same applies to declarative shadow DOM, since `<template shadowrootmode="open">` is an ordinary template here.
The three available workarounds are all unsatisfactory:
1. Parse `innerHTML` into a scratch document. Costs a full extra parse and yields nodes owned by a different document, which cannot be moved back.
2. `Dom\HTML_NO_DEFAULT_NS`. Makes the contents ordinary children, but drops the XHTML, SVG and MathML namespaces document-wide, means `Dom\HTMLElement` is never used, and serializes void elements as `<input name="x"></input>`.
3. The `getElementById` route above, which only works when a descendant has an `id`.
For comparison, the legacy `DOMDocument::loadHTML()` reaches template children directly, so code migrating to `Dom\HTMLDocument` loses this capability.
### Note
[dom_additions_84](https://wiki.php.net/rfc/dom_additions_84) left `HTMLElement` properties out on the grounds that "no one really asked for that feature so far". This is a request for that feature, for the one property whose absence makes data unreachable rather than merely inconvenient. [#17110](https://github.com/php/php-src/issues/17110) contains a maintainer confirmation that `content` does not exist, but that issue was about a non-standard XPath traversal flag and was closed by the stale bot; `content` is a standard property, so no RFC seems needed, comparable to [#18550](https://github.com/php/php-src/issues/18550).