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
$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 themActual 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:
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:
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:
$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:
- Parse
innerHTML into a scratch document. Costs a full extra parse and yields nodes owned by a different document, which cannot be moved back.
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>.- 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 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 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.
Description
Dom\HTMLDocumentparses<template>contents into an internalDocumentFragment, which is correct per spec, but there is noDom\HTMLTemplateElementclass and nocontentproperty, so the parsed contents cannot be reached through the DOM API at all.innerHTMLreturns them as a string and serialization round-trips them, but no node inside a template can be obtained.The empty
childNodesis correct and I am not reporting it. The missing accessor is the problem.Actual output
Expected output
$tplshould be aDom\HTMLTemplateElement, and$tpl->contentshould be theDom\DocumentFragmentholding<input name="x">, so that$tpl->content->querySelectorAll('input')returns 1 node.Per the HTML Standard, 4.12.3 The
templateelement:with IDL:
So
contentis the spec-mandated way to reach these nodes, and it is the only one.childNodesbeing empty is correct precisely becausecontentis 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:$fragsupportschildNodes,querySelectorAll(),textContentandsaveHtml()normally.ext/dom/private_data.halready stores it intemplate_fragmentsand already exposesphp_dom_ensure_templated_content(), so exposing it as acontentproperty 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.phpon master has neitherHTMLTemplateElementnorcontent.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 thehtml:prefix bound tohttp://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-matchinginnerHTML. The same applies to declarative shadow DOM, since<template shadowrootmode="open">is an ordinary template here.The three available workarounds are all unsatisfactory:
innerHTMLinto a scratch document. Costs a full extra parse and yields nodes owned by a different document, which cannot be moved back.Dom\HTML_NO_DEFAULT_NS. Makes the contents ordinary children, but drops the XHTML, SVG and MathML namespaces document-wide, meansDom\HTMLElementis never used, and serializes void elements as<input name="x"></input>.getElementByIdroute above, which only works when a descendant has anid.For comparison, the legacy
DOMDocument::loadHTML()reaches template children directly, so code migrating toDom\HTMLDocumentloses this capability.Note
dom_additions_84 left
HTMLElementproperties 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 contains a maintainer confirmation thatcontentdoes not exist, but that issue was about a non-standard XPath traversal flag and was closed by the stale bot;contentis a standard property, so no RFC seems needed, comparable to #18550.