Load embed JS async and without document.write

[reefdog]

Copying and genericizing the description of this pull request.

Our document, note, and search embed codes all follow this pattern (using pseudo-code):

<div id="foo-1234"></div>
<script src="loader.js"></script>
<script>
  loadEmbed('//www.documentcloud.org/path/to/foo-1234.json');
</script>

So, our current codes depend on render-blocking synchronous script loading:

1. loader.js loads remotely (blocking)
2. loader.js uses document.write to add resource-specific embed.js to the DOM (bad practice and being deprecated)
3. embed.js loads remotely (blocking)
4. loadEmbed called via inline script

For backwards compatibility with existing embed codes, we're stuck with 1 and 4, but we can fix 2 and 3.

What this PR will do

1. Define the inline embed-loading functions (loadEmbed in the pseudo-code up there) as queuing functions in the loader JS, unless the embed JS is already available, then skip the queue and load immediately
2. Have the loader JS use document.createElement (instead of document.write) to add the embed JS to the DOM, and only if necessary, and using async so page render can continue
3. Rename the curerent embed-loading functions in the embed JS (dc.embed.loadNote/dc.embed.load/DV.load) for the loader JS to call once the embed JS is available, but also alias the old name to the new name when the old name isn't defined (for scenarios where the embed JS is used without the loader JS)

One downside: we now require IE8+ IE9+.

What this PR won't do

1. Change the embed codes: Since we need to maintain compatibility with the existing embed codes anyway, this work doesn't touch them.
2. Make our embeds work better in pjaxy environments: See this comment.
3. Unify embed loaders: This is a pet project of mine, and won't be hard to do, but it's just outside the scope of this PR. So despite heavy duplication across the various loaders, this doesn't alleviate that yet.

Status:

• Note embeds
• Document embeds
• Search embeds

[knowtheory]

we now require IE8+.

That's fine.

[reefdog]

Gah, I actually meant IE9+, both here and in the other PR, but it seems you read my mind anyway and still agree.

Again, I can work around that and support IE8 (and maybe earlier) without much trouble. It'll just be a bit more code in the loader.

[reefdog]

Need to put this somewhere, may as well be here: if we ever wanted to ensure IE8 compatibility, we'd have to use the following addEventListener polyfill:

var on = function (el, eventName, handler) {
  if (el.addEventListener) {
    el.addEventListener(eventName, handler);
  } else {
    if (el.tagName.toLowerCase() == 'script' && eventName.toLowerCase() == 'load') {
      el.attachEvent('onreadystatechange', function() {
        if (el.readyState == 'complete' || el.readyState == 'loaded') {
          handler.call(el);
        }
      });
    } else {
      el.attachEvent('on' + eventName, function() {
        handler.call(el);
      });
    }
  }
};

And replace the $= attribute matcher with just = in the querySelectors.

[knowtheory]

Just to be definitive, have you pulled the IE numbers from Google Analytics?

[knowtheory]

I'll take a look at pulling the last month's worth of raw logs.

[reefdog]

In October 2016, IE6-IE8 combined were 0.2% of our total website/platform visits. That doesn't track embeds. For YTD 2016, IE6-IE8 were 0.43%.

[reefdog]

Got the LGTM from @knowtheory via Slack. Away we go!