This part 2 of a 3 part article on Kermit. Please read part one 1 there: Kermit - part 1
Kermit started as my quest to simplify page element tracking with Adobe Analytics. I felt there was redundancy in the code required. I wanted to see all the analytics configuration for a whole page at a glance but also inspect a link and see if it was tracked. HTML5 data- attributes seemed to be the solution. I could add the analytics page view details to the body tag and the element interaction parameters to the element itself. The body tag would not work with single page applications, and AngularJS wipes out all attributes from its empty placeholder div, [ng-view] or [ui-view] in AngularJS parlance. AngularJS does leave these HTML5 data- attributes on any of the elements in the HTML fragments untouched. The HTML fragments can start with an empty div with data- attributes to describe the page view.
After much tweaking, I added handy functions, one of them providing a summary of all data- attributes for the analytics implementation using client-side Javascript support for XSLT. DOM selectors in Javascript only let you select elements based on the tag name or the full attribute name but not attributes starting with a given string, data- in our case. XSLT can though, and you can fall back on a class="kermit". I felt I had something of a game changer on my hands, a new approach to web analytics tagging I had never heard of until I spoke with Phil Pearce.
Phil is a Google Tag Manager and implementation expert, whom I have met at MeasureCamp London. He has published a book on GTM which I picked at one of his talks at MeasureCamp. I explained to Phil this new approach when he pulled a copy of his book and showed me a page where he was doing just that. Besides, GTM can read these data-attributes directly without needing a Javascript framework. I found later that, although uncommon, a few others have been advocating a similar approach as early as 2012 except for one notable exception: nothing about how to handle traditional websites and single page applications in a single consistent way, crickets. I named my approach Kermit for no interesting reason.
Javascript supports various events to capture a URL hash change or adding items to the browser history, but there are too many cases to consider. After some research, I stumbled upon a method to capture so-called DOM mutations. When a single-page application updates the page a DOM mutation occurs. Even as small a change as an element attribute changes triggers a mutation event. A page with five tabs using CSS tricks to show the contents of one tab and hide the other four is also a trivial case: you update the value of the data- element containing the page name in response to the tab click triggering a mutation triggering a page view. A pop-up will load a full document which would trigger a page view as it renders. Except for Opera Mini the browsers have supported DOM mutation events for some time, albeit in different forms.
