Research: Modifying a custom elements light dom is not working in Edge

[pr3tori4n]

Research: Modifying a custom elements light dom is not working in Edge

[pr3tori4n]

Ok I've got some good news. I was able to get native behavior in Edge working pretty smooth directly working with the polyfills provided from webcomponents.org using native web components.
Example code, if you're interested.
So, we know that with the right polyfill, native behavior works on Edge.

I think that settles the amount of investment we need to make on our side - we have an open bug in the Stencil repo. Once we have the support plan, we can request they prioritize fixing that bug.

That should take care of Edge behavior without additional effort on our part. Sound good?

[driskull]

Option 1: set a requirement that elements that are going inside a custom element

What if we document and set a requirement that elements that are going inside a custom element need to go into a container element and the container element needs to be within the custom element when initially defined.

If you need to modify the content later, you have to do so through the container node instead of through the custom element.

This would avoid the issue where content added at a later time shows up in the incorrect place in Edge.

Wrong

<calcite-action id="my-action"></calcite-action>

document.getElementById("my-action").innerHTML = "<svg />";

Correct

<calcite-action id="my-action">
  <div id="action-container"></div>
</calcite-action>

document.getElementById("action-container").innerHTML = "<svg />";

Pros

• Slotted content position never changes

Cons

• It's a workaround and inconvenient
• If we're using an observer, we would need to observe the container instead of the slot.
• Slotted container is always there so no way to conditionally display slot

[driskull]

Option 2: Create polyfill using data attribute

Add a data-attribute to the container where slots should be placed and use a query to identify where the slot content should be placed before placing in edge. We could have a utility that handles this.

<div key="icon-container" aria-hidden="true" class={CSS.iconContainer} data-slot>
  <slot />
  <div data-slot="slot-name">
    <!-- named slot content -->
  </div>
</div>

Pros

• Can accept multiple nodes within a slot

Cons

• Requires a utility to figure out where to put the content if edge instead of using appendChild
• Requires slot always have a container around it

[driskull]

Option 3: Use observer and utility to move content

If the component uses slots, have a mutation observer to monitor the host element for childList changes. If a childList change occurs, move the nodes into the correct place. It could inspect the node's slot attribute and place them where they should go.

Pros

• Will accept multiple nodes
• Would work with appendChild

Cons

• Requires an observer (observer could only be setup if Edge?)
• May conflict with native slot support. Or just wouldn't be setup if native slot support exists. [NEEDS TESTING]
• Requires a utility to move the nodes to the correct place. We would have to figure out a way to identify the correct place location.

[pr3tori4n]

@driskull I've numbered your options so they are a bit easier to reference.

#3 mirrors my expectation of what the official polyfill should handle. So I think that's the best choice. My reasoning is that 1) it doesn't introduce any new learning curves for end-users, like needing to learn about a new utility function or a data-attribute. And because of that 2) It's pretty future-proof, once Edge is up to spec, we drop it and everything works like normal. With the other solutions, we may be stuck with supporting that architecture for a long time after this is no longer an issue. 3) We should be able to do feature-detection of some sort and only "enable" this behavior in the browsers that need it - so we don't impact native behavior in browsers with shadowdom support.

If we go this route, I'd like to look into contributing this directly to the polyfill and opening up a PR here. That way we can keep our component code more clutter-free.

[pr3tori4n]

On another note - I'm still trying to find if there's an existing bug report and possible patch on its way that may save us the effort.

[pr3tori4n]

There's a wrapper that shadyDOM applies that seems to be for supporting lightdom operations. https://github.com/webcomponents/shadydom/blob/master/src/wrapper.js#L31
Investigating this further.

More info: https://www.webcomponents.org/polyfills#wrappers

[pr3tori4n]

@jcfranco @driskull should we keep this open until the Stencil bug is addressed? Or are we ok with closing this?

[driskull]

I'm ok with closing it if we have another issue to track the stencil bug

[pr3tori4n]

if we have another issue to track the stencil bug

If we want to keep an issue open to remind us I'd suggest leaving this one opened rather than creating a new one. I'm going to unassign myself from it though - since I'm not actively working on it.

[pr3tori4n]

@jcfranco @driskull I created a Wiki page to track these bugs/issues. We good to close this now?

[jcfranco]

Awesome, thanks!