Use explicit HTML wrapper in DOMParser for consistent output in brows…

…er and linkedom (for SSR) Before: ```js // Browser (Chrome, Firefox) new DOMParser().parseFromString(`<div>foo</div>`, "text/html").body.outerHTML; // '<body><div>foo</div></body>' // `linkedom` ❌ new DOMParser().parseFromString(`<div>foo</div>`, "text/html").body.outerHTML; // '<body></body>' ``` After (consistent matching output): ```js // Browser (Chrome, Firefox) new DOMParser().parseFromString(`<!DOCTYPE html><html><body><div>foo</div></body></html>`, "text/html").body.outerHTML; // '<body><div>foo</div></body>' // `linkedom` new DOMParser().parseFromString(`<!DOCTYPE html><html><body><div>foo</div></body></html>`, "text/html").body.outerHTML; // '<body><div>foo</div></body>' ``` --- `linkedom` goal is to be close to the current DOM standard, but [not too close](https://github.com/WebReflection/linkedom#faq). Focused on the streamlined cases for server-side rendering (SSR). Here is some context around getting `DOMParser` to interpret things better. The conclusion was to only support the explicit standard cases with a `<html><body></body></html>` specified instead of adding the magic HTML document creation and massaging that the browser does. - WebReflection/linkedom#106 - WebReflection/linkedom#108
element-hq · Feb 12, 2022 · f5dde30 · f5dde30
1 parent 75e2618
commit f5dde30
Showing 1 changed file with 1 addition and 1 deletion.
diff --git a/src/platform/web/parsehtml.js b/src/platform/web/parsehtml.js
@@ -64,6 +64,6 @@ export function parseHTML(html) {
     // If DOMPurify uses DOMParser, can't we just get the built tree from it
     // instead of re-parsing?
     const sanitized = DOMPurify.sanitize(html, sanitizeConfig);
-    const bodyNode = new DOMParser().parseFromString(sanitized, "text/html").body;
+    const bodyNode = new DOMParser().parseFromString(`<!DOCTYPE html><html><body>${sanitized}</body></html>`, "text/html").body;
     return new HTMLParseResult(bodyNode);
 }