Event labels for DOM elements

[alexei]

Hello,

I'm using your plug-in in a project and found it unfriendly to publish selectors, ids etc. in GA. Where I come from, the people who need that data are not techies, so I added the possibility to set custom labels for elements.

Alexei

[alexei]

I added a new feature (to track visible elements only), but it seems GitHub took the changes as a whole, instead of a separate pull request. Sorry for that.

[alexei]

Previous commit removes jQuery dependency #17

[robflaherty]

So, just so I understand, the problem is that the selectors are not user-friendly or readable in the GA dashboard, right? Instead of putting the labels directly on the dom elements, what if we had the labels defined as part of the initialization, like this:

elements: [
        { selector: '#comments',
          name: 'Comments'
        },
        { selector: '#footer',
          name: 'Footer'
        }
      ]

[alexei]

This PR targets 3 things:

1. Labels for elements
   I chose to use data-* attributes because this is why they were invented in the first place and it's the least expensive in terms of code changes and compatibility i.e. it's easy to implement it in the library, it's easy to deploy on existing projects (with no changes) and doesn't require developers to initialize the library by inlining a small script inside their HTML pages. It also might be possible to play nice with WYSIWYG tools that disallow JavaScripts. So yeah, this approach seemed natural vs. an extra option or a more complex elements structure. It also allows to implement generic selectors instead of an array of items that target specific nodes i.e. "section" vs. ["#section-1", "#section-2" etc.]
2. The second set of commits covers the problem of hidden elements
   In my project, I have a responsive page with sections that are visible or hidden depending on the device i.e. certain sections are visible on mobile devices while remaining hidden on desktop computers. We don't serve different content to different devices. So I noticed that hidden elements do trigger events although they shouldn't. I do believe, for stats purposes, it is possible to segment GA reports however, again, omitting hidden elements seems like the best approach i.e. vs telling marketing folks how to read GA data.
3. jQuery
   While I'm a big fan of jQuery, I sometimes find it unnecessary. My approach is to use the right tool for the job. I use Angular, jQuery, Zepto, Ender, "VanillaJS" etc. and I use them sparingly, depending on the project's needs. So I created a standalone version of scrolldepth that should work across browsers (IE8+) and do so on it's own.

[alexei]

"It also allows to implement generic selectors instead of an array of items that target specific nodes i.e. "section" vs. ["#section-1", "#section-2" etc.]" - I mean in the future

[robflaherty]

@alexei,
Thanks for the detailed explanation. There's too much going on in this PR for me to merge it in but I think you've raised some interesting points. I'm going to close this but open up two tickets for the data labels and visibility questions.

Thanks again.