Add use counters for WebVTT

[foolip]

VTTCue is for any VTTCue creation, whether from the JS constructor or
the WebVTT parser.

VTTCueParser is for the creation of a WebVTT parser for a <track>
element.

VTTCueRender is for when a cue is actually displayed, which would be
on top of a playing <video>.

[foolip]

This raises some questions about use counters for me that I think will need attention, so that usage_stats is a somewhat consistent concept.

Two kinds of "usage" that are clear is (1) used in the page and (2) observable or interacted with by the user.

For example, a <dialog> element being present in the page vs. a <dialog> element being opened for a user. Or (a harder case) there being a button to go fullscreen and element.requestFullscreen() actually being called and the page going fullscreen.

[foolip]

@atopal @ddbeck what do you think about the distinction between "potential" and "actual" feature usage?

Some additional thoughts:

• For constructors and methods, actual usage is easy to measure with browser metrics but potential usage requires static analysis of code paths never actually run.
• For IDL attributes, actual usage is hard to measure, because it's common for a value to be read without being used for anything at all.
• For CSS properties, potential usage is easy, but to know if a property had any effect requires hand-written metrics
• For markup features, potential usage is easy as it's in the markup. A lot of the time that's synonymous with actual usage; if a <picture> element appears in the page it's also rendered. But for <dialog> and popover the features aren't really being used until the dialog or popover is opened.
• For JavaScript features, we mostly don't have browser usage metrics, and I expect adding them would result in performance regressions.

[atopal]

Re the question of usage by devs vs usage by users. It depends on what we are trying to do. My initial reaction is to stick with usage by devs, because usage by users is mediated through decisions made by devs and that's a whole other discussion compared to "do developers use a given feature?". But I'm starting from the assumption that what we are interested in is questions like that and we want to know what drives adoption by developers so we can influence that in the future.

[ddbeck]

My initial reaction is to stick with usage by devs

That's my reaction too. I'm approaching this with the expectation that we're being generally developer-oriented and it calls back to the key question of "can I use this?" The frequency of visitors actually triggering a feature may not be especially interesting to a web developer and yet the ability to rely on the feature's existence may be extremely important. Some accessibility features (including subtitles) may illustrate a not-uncommon story: perhaps only a small number of visitors actually make use of it, but the developer can't ship without it.

[foolip]

OK, so let's go ahead and merge this. If we interpret the data by taking the largest of the use counters, that would do something reasonable enough in this case. I'll file a new issue about the definition of usage.

[foolip]

I've filed #66.