Skip to content

Commit

Permalink
Keep fragment in the template's document during clone
Browse files Browse the repository at this point in the history
The template's document doesn't have a browsing context, so
custom elements aren't upgraded. This change defers upgrading
any custom elements inside the template until after the
treewalker that links the Parts to the DOM.
This is important because custom elements can modify their DOM
at upgrade time (e.g. when using ShadyDOM).

Fixes #231
  • Loading branch information
bgotink authored and justinfagnani committed May 19, 2018
1 parent f5f6a4e commit 8697b40
Showing 1 changed file with 4 additions and 1 deletion.
5 changes: 4 additions & 1 deletion src/lit-html.ts
Original file line number Diff line number Diff line change
Expand Up @@ -729,7 +729,10 @@ export class TemplateInstance {
}

_clone(): DocumentFragment {
const fragment = document.importNode(this.template.element.content, true);
// Clone the node, rather than importing it, to keep the fragment in the
// template's document. This leaves the fragment inert so custom elements
// won't upgrade until after the main document adopts the node.
const fragment = this.template.element.content.cloneNode(true);
const parts = this.template.parts;

if (parts.length > 0) {
Expand Down

4 comments on commit 8697b40

@depeele
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change results in contained custom elements never becoming fully adopted even when this element is finally adopted. This means that contained elements will always be matched by the :unresolved CSS pseudo-property.

In https://codepen.io/depeele/pen/QBdZyo using lit-html:v0.10.0 the contained test-item is considered resolved in the final document.

In https://codepen.io/depeele/pen/PBWyzB using lit-html:v0.10.1 but otherwise the same code, test-item is not considered resolved in the final document.

@bgotink
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like you've found a browser bug. I don't see any red border when opening the v0.10.1 version in Safari.

@depeele
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out, the WebComponents standards committee decided to rename :unresolved to :not(:defined) (w3c/webcomponents issue 418).

See https://codepen.io/depeele/pen/gjGPRy which uses lit-html:v0.10.1 and the new pseudo-property.

@bgotink
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a relief!

Please sign in to comment.