# Web-components interop (childNode issues)

**URL:** <https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730>\
**Category:** Learn\
**Created:** [June 2, 2019, 8:29pm UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730 "2019-06-02T20:29:04Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![luke](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/luke/32/709_2.png) [@luke](https://discourse.elm-lang.org/u/luke)\
**Post date:** [June 24, 2019, 8:19pm UTC](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730/6 "2019-06-24T20:19:23Z")

</div>

> [@ciekawy](#):
>
> OTOH with rise of new standards and frameworks would be great to have some common way to coexist.

This is supposed to be achieved through shadow DOM. Shadow DOM isn’t perfect and there are certainly legitimate reasons not to use it right now, but it’s not clear to me why `ion-header` and `ion-item` would need to do so.

Unfortunately there’s no way Elm’s virtual DOM can detect and import DOM changes from outside the system without sacrificing its rendering speed, so I wouldn’t expect it to change to accommodate this use case. Something you might be able to try as a workaround is to declare your own custom element which renders your `ion-header` component within its own shadow DOM tree to hide its behavior from the Elm virtual DOM.

---

_[View the full topic](https://discourse.elm-lang.org/t/web-components-interop-childnode-issues/3730)._