Confirmed: <http://3v4l.org/nrYAR>.

According to the "Document Object Model Core" specification[1]
nodeValue is supposed to yield null for Element nodes, so the
behavior may be considered as bug. However, it works this way
since the beginnings of the DOM extension, and the
documentation[2] isn't particularly clear with regard to the exact
behavior, so changing the behavior would introduce a BC break
which is not easily noticed.

Nonetheless, this should be fixed for PHP 7 (even though beta1 has
already been tagged, which marks the feature freeze), in my
opinion.

[1] <http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-F68D080>
[2] <http://de2.php.net/manual/en/class.domnode.php#domnode.props.nodevalue>

The fix for this bug has been committed.

Thank you for the report, and for helping us make PHP better.

Could that fix please be noted in UPGRADING?

That just broke my code... :-/

Yes, it's non-standard, but still an useful side-effect,

Yes, this is a bug, but I'd like to see it reverted and marked as WONTFIX.

Fixing it has exactly zero benefits (except spec compliance) while it introduces a BC break and removes a useful features.

Among other things, the fix breaks PHPUnit:

https://revive.beccati.com/bamboo/browse/PHP-PHPUN-477

I have reverted the fix and the respective UPGRADING and NEWS
entries.

> Fixing it has exactly zero benefits (except spec compliance)
> while it introduces a BC break and removes a useful features.

IMHO, standard compliance is a benefit, especially as the manual
states[1]:

| The DOM extension allows you to operate on XML documents through
| the DOM API with PHP 5.

Furthermore I don't see a good reason to use DOMNode::nodeValue
instead of DOMNode::textContent to get the text content of a node.

[1] <http://www.php.net/manual/en/intro.dom.php>

Hi,

Please correct it again. 
It's way better to have standard compliance than having code relying on non documented, unwanted behavior. Code relying on non standard is not portable and reference implementation of DOM API in PHP should be standard compliant.
Moreover the feature is not removed since it already exists with textContent as you pointed out.

The only negative point is BC break but it is only a minor point since it's so easy to change nodeValue for textContent in that case.
It's sufficient to explain this possible fix in the release note.

If, for a reason I don't see, it's more clever to have textContent than having null in nodeValue of DOMElements, then it should be first explained why. And it should be explained not only here but also at the W3C where the debate should be.

Best regards,
   Laurent Lyaudet

textContent seems like a good alternative, missed that, it's probably fine with a small explanation in UPGRADE then.

After some further discussion on the internals mailing list[1], it
seems to be best to postpone the "fix" until PHP 7.1.

[1] <http://markmail.org/message/d7bwuawbccnjklvm>