Parsing splits one text run into several Text nodes at each character reference (`<p>a &amp; b</p>` gives 3 child nodes)

Offen Anfängerfreundlich
#353 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 5 Tagen

@johnhldiver-beep arbeitet bereits daran.

Seit 30.10.2026.

  • #361 von @johnhldiver-beep — offen

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
68/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
html, javascript
Bereich
backend, web-dev

Rechercherichtung

Beginne mit dem ontext-Handler in esm/shared/parse-from-string.js, der laut Issue für jeden Parser-Callback einen Text-Knoten anhängt. Vergleiche sein Verhalten mit dem DomHandler von htmlparser2 und füge dann einen Regressionstest für Markup mit Zeichenreferenzen hinzu. Als erledigt gilt die Arbeit, wenn das Parsen des Beispiels einen Text-Knoten mit den Daten "a & b" erzeugt und die bestehende Testabdeckung bei 100 % bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Parsing <p>a &amp; b</p> gives the <p> three Text nodes ("a ", "&", " b"). The HTML parsing algorithm appends each character to the previous Text node, and jsdom gives one Text node, "a & b". Code that walks childNodes and treats each Text node as one run sees extra runs wherever the source has an entity. normalize() merges them afterwards, but every consumer of parsed output has to know to call it on every subtree, and a spec parser never produces the split in the first place ("insert a character": https://html.spec.whatwg.org/multipage/parsing.html#insert-a-character).

Asks:

  1. Should the parser merge text into the previous Text node when the previous sibling under the same parent is a Text node, as the HTML parsing algorithm does?
  2. If yes, I can open a PR that changes esm/ only, with a test, keeping coverage at 100%.

Environment: linkedom 0.18.14 (npm, latest) and main at e2ee208, htmlparser2 10.1.0, Node 24.14.1, macOS.

Test case:

import { DOMParser } from 'linkedom'

const doc = new DOMParser().parseFromString('<!doctype html><html><body><p>a &amp; b</p></body></html>', 'text/html')
const p = doc.querySelector('p')
console.log('textContent:', JSON.stringify(p.textContent))
console.log('childNodes.length:', p.childNodes.length)
console.log('childNodes data:', JSON.stringify([...p.childNodes].map((n) => n.data)))

Output:

textContent: "a & b"
childNodes.length: 3
childNodes data: ["a ","&"," b"]

Expected: childNodes.length: 1, data ["a & b"] (what jsdom 29.1.1 returns for the same markup).

Input linkedom Text nodes jsdom Text nodes
<p>a and b</p> 1 1
<p>a &amp; b</p> 3 1
<p>x &lt; y &gt; z &#169;</p> 6 1

parseHTML gives the same result as DOMParser (3 nodes for <p>a &amp; b</p>).

Raw output (npm 0.18.14, main e2ee208, variants, htmlparser2)
$ node repro.mjs   # linkedom 0.18.14 from npm
textContent: "a & b"
childNodes.length: 3
childNodes data: ["a ","&"," b"]
$ node repro-main.mjs   # main e2ee208 esm/
textContent: "a & b"
childNodes.length: 3
childNodes data: ["a ","&"," b"]
$ node variants.mjs
no entity:       1 ["a and b"]
&amp;:           3 ["a ","&"," b"]
&lt; &gt; &#169;: 6 ["x ","<"," y ",">"," z ","©"]
parseHTML:       3
$ node htmlparser2-ontext.mjs   # htmlparser2 10.1.0, decodeEntities: true
htmlparser2 ontext calls: ["a ","&"," b"]
$ node jsdom-control.mjs
jsdom childNodes.length: 1 ["a & b"]

Where it comes from: htmlparser2 with decodeEntities: true calls ontext once per piece around each character reference. The ontext handler in parseFromString appends a new Text node for every call:

https://github.com/WebReflection/linkedom/blob/e2ee20813e4b3ae946d7ba41621ddf3698431989/esm/shared/parse-from-string.js#L92-L98

htmlparser2's own DomHandler merges each ontext piece into the previous Text node (domhandler 5.0.3, lib/index.js, ontext), so with the same callbacks it yields one node for <p>a &amp; b</p>.

No existing issue found for this; the closest are #62 and #71, which are about serializing entities, not the node split.

Vorherrschende Sprache
HTML
Sterne
2.1k
Forks
117
Ø Merge
4 T. 13 Std.
Gemergte PRs (30 T.)
2

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus WebReflection/linkedom

Alle Issues in WebReflection/linkedom

Ähnliche Issues

Weitere Issues zu Backend & API Design

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.