However, it offers powerful tools for encapsulation and separation of concerns, and especially in lieu of clumsy iframe embeds it might make a lot of sense from a web development point of view. I have a gut feeling that the shadow DOM is somewhat of a mystery to many web analytics developers simply because it’s not the most common way to add elements to the web page. Hopefully this article has been instructive. It does require some cooperation with the developers, and you’d also need to justify why the mode is set to closed in the first place if the developers add an opening by way of a global variable. In the sample above, the global variable _shadowRoot maintains a reference to the shadow DOM, and thus you can use methods like window._shadowRoot.addEventListener(.) to manipulate and interact with elements within the shadow DOM. If ( 'composed' in event & typeof posedPath = 'function') ) Set to false if you want to track all events and not just those in shadow DOM Set to false if you don't want to use capture phase In Google Tag Manager, create a Custom HTML tag, and type or copy-paste the following code. We can use this information to build our listener. The very first member in the array is the item that was actually clicked (unless the shadow DOM was closed, but we’ll get back to that in a minute). Luckily, we can use the posedPath() method to get an array that represents the path the event took as it bubbled up. The shadow DOM could be a huge, sprawling thing, so we need precision. All events that take place in the shadow DOM are auto-delegated to the parent of the #shadow-root. However, we are still faced with the problem introduced in the beginning of this article. Like these:įor events that have composed set to true, we can attach a custom event listener on the document node, for example, and the events that take place within the shadow DOM will propagate to our listener (assuming they also bubble, or the listener has been set to detect the capture phase instead). Typically, the exceptions are events that are not based on UI interactions. The main difference with the shadow DOM is that events that start making their way up only cross the shadow DOM boundary if they have the property composed set to true. Some events bubble up towards the top of the DOM tree, some stay on the node where the event was registered. An event is registered, and it populates a path through the layers of the site during the capture and bubble phases. How event handling works with the shadow DOMĮvent listeners within the shadow DOM work just like event listeners on regular DOM structures. Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox! But we can use a custom event listener.įor more details on how event handling within the shadow DOM works, take a look at this excellent article on the topic. We can work around this! We can’t use GTM’s built-in triggers as they don’t let us access the event object itself. Similarly, because the shadow DOM’s contents are hidden from the parent structure, the matches CSS selector predicate can’t be used to see what’s inside the clicked element. In this example, GTM would populate the click variables so that the click appeared to land on the when it actually landed on the element within #shadow-root.
0 Comments
Leave a Reply. |