I wanted to note the things that are weird in jsdom right now that parse5 could help us with. I expect many of these are addressed in 2.0, or maybe even already addressed in 1.5 if we use the parse5 API instead of the htmlparser2 tree adapter. But I wanted to confirm with you.

<template> serialization

We use parse5 for serialization. Serializing <template> requires serializing its contents. Currently parse5 does treeAdapter.getChildNodes(node)[0] and assumes that that will give the "template contents" document fragment. This causes jsdom to implement treeAdapter.getChildNodes as:

exports.getChildNodes = function (node) {
  // parse5 treats template elements specially, assuming you return an array whose single item is the document fragment
  return node._templateContents ? [node._templateContents] : node.childNodes;
};

It would be better to have a dedicated getTemplateContents function that is only used for templates.

<template> parsing

Similarly, <template>s are being handled specially in parsing. It appears that when parsing documents containing <template>, parse5 has a new '#root' node surrounding the template contents. When we encounter that, we need to take all of the root node's parse5 children, convert them to jsdom-children, and jsdom-insert them into the current "parent", which is a jsdom-template.

As a separate case, when parsing children of a <template> context using parseFragment, we need to note that case specially, and jsdom-insert the resulting jsdom-children into the jsdom-context node's template contents, instead of directly into the jsdom-context node.

It would be better if there were something matching "appropriate place for inserting a node" more closely, which could use the treeAdapter.getTemplateContents somehow. Then parse5 could do all the work of figuring out where to place template children for us.

My suggestion here is a bit hazy as I'm not sure how, in an ideal world, jsdom should be interacting with parse5. Its current setChild abstraction seems a bit strange.

Attributes

Currently we get attributes as an object map of local names -> values, plus two other maps of x-attribsPrefix and x-attribsNamespace. I'd prefer an (ordered) array of { localName, prefix, namespace }.