We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If I manually modify a DOM document and add an entity reference, HTML5::saveHTML() does not give the same result as DOMDocument::saveHTML():
HTML5::saveHTML()
DOMDocument::saveHTML()
$html5 = new Masterminds\HTML5(['disable_html_ns' => TRUE]); $dom = $html5->loadHTML('<body>'); $node = $dom->getElementsByTagName('body')->item(0); $node->appendChild($dom->createElement('span', 'Identité')); print $dom->saveHTML() . "\n"; print $html5->saveHTML($dom) . "\n";
outputs
<!DOCTYPE html> <html><body><span>Identité</span></body></html> <!DOCTYPE html> <html><body><span>Identit</span></body></html>
This was reported in the Drupal project, which has recently switched to using this library instead of using DOMDocument to parse and serialize HTML: https://www.drupal.org/project/drupal/issues/3416204
This is because Traverser::node() does not handle XML_ENTITY_REF_NODE. Should the switch statement and rules class be extended to support this case?
Traverser::node()
XML_ENTITY_REF_NODE
The text was updated successfully, but these errors were encountered:
Any news on this?
Sorry, something went wrong.
hm, interesting. are you willing to provide a fix for this?
No branches or pull requests
If I manually modify a DOM document and add an entity reference,
HTML5::saveHTML()
does not give the same result asDOMDocument::saveHTML()
:outputs
This was reported in the Drupal project, which has recently switched to using this library instead of using DOMDocument to parse and serialize HTML: https://www.drupal.org/project/drupal/issues/3416204
This is because
Traverser::node()
does not handleXML_ENTITY_REF_NODE
. Should the switch statement and rules class be extended to support this case?The text was updated successfully, but these errors were encountered: