Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

Dom\HTMLTemplateElement is missing, so template contents are unreachable from the DOM API

未關閉
#23,334 0 則留言 0 個 reaction 已指派 1 人 在 GitHub 檢視

@devnexen 已經在處理了。

開始於 2026年8月17日。

評估

這個 Issue 還沒有評估資料。

描述

Bug Extension: dom Status: Verified
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 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:

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:

  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 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.

主要語言
C
星號
40.4k
分支
8.2k
平均合併
2 天 17 小時
30 天內合併 PR
115

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

php/php-src 的其他 Issue

查看 php/php-src 的全部 Issue

相似的 Issue

更多 C Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。