\Dom\HTMLDocument have null textContent, unlike \DOMDocument

[momala454]

Description

The following code:

<?php
$html = 'abc&lt;def<br>g';

$dom = \Dom\HTMLDocument::createFromString($html, options: LIBXML_NOERROR | LIBXML_HTML_NOIMPLIED);
var_dump($dom->textContent);

$dom = new \DOMDocument(encoding: 'UTF-8');
$dom->loadHTML($html, LIBXML_NOERROR | LIBXML_HTML_NOIMPLIED);
var_dump($dom->textContent);

https://3v4l.org/t9WVN

Resulted in this output:

NULL
string(8) "abc<defg"

But I expected this output instead:

string(8) "abc<defg"
string(8) "abc<defg"

It may be not a bug, but in this case, how to simply get the same result ?

PHP Version

8.4.3

Operating System

No response

[damianwadley]

I believe this is correct behavior:

• WHATWG says that textContent is only defined for document fragments, elements, attributes, and CDATA nodes
• DOM 3 says more or less the same thing, including that document nodes should have their "content" be null
• If I try document.textContent in my browser, it evaluates to null

I'd wager that the old DOMDocument implementation that provided a value simply wasn't correct in doing so.

CC @nielsdos

As for how to get the same result, I would first question whether textContent accurately reflects what you're trying to do, but if you're sure it does then perhaps you just need to join the textContents of the document's child nodes?

[momala454]

for the goal, it is to get the text version (so with no html tags, and html entities converted by example) of the whole document.
Looping all nodes is a solution, but require a bit of code https://3v4l.org/A80A4
it's obviously longer. Is it the cleanest solution ?

[TimWolla]

<?php
$html = 'abc&lt;def<br>g';

$dom = \Dom\HTMLDocument::createFromString($html, options: LIBXML_NOERROR);
var_dump($dom->documentElement->textContent);

works. Note the removal of LIBXML_HTML_NOIMPLIED and the use of documentElement.

[ndossche]

What others have said is right: textContent is supposed to return NULL on a document. So this was a bug in \DOMDocument. So this is not a bug, but expected behaviour. (Thanks!)

Tim gave an excellent example of how to solve this with standard properties.

[momala454]

Thanks all!