[whatwg] Promise-vending loaded() & ready() methods on various elements

[Jake Archibald]

One of the problems with async scripting is doing something when/if it's
ready. A complete solution looks like this
https://gist.github.com/jakearchibald/7662e012462c7537a075, it would be a
lot easier if we could just do:

thing.loaded().then(function() {
  console.log('loaded');
}, function() {
  console.log('failed');
});

== document.ready() ==

Vends a promise gated on DOMContentLoaded.

Use-case: Async-loaded scripts that want to carry out operations on a
complete DOM. Most JS libraries have a method to do this.

== img/link/script/document/iframe .loaded() ==

If the element hasn't loaded or is loading, vend a promise that
resolves/rejects on its load/error event.
If the element has fired load/error and isn't loading due to a source
change, vend a resolved/rejected promise.

Use-cases:
* Loading an image before using in a canvas
* Waiting until a stylesheet has loaded before using script to read
computed styles
* Waiting on an async html import to load before accessing its import
property (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25007)
* document.onload that works for scripts loaded after the event
* Waiting for an iframe to fully load before accessing contents

== XHR .send() ==

Currently returns void, but should return a promise. Could add a loaded()
method if changing the return value of send is risky.

There are also possibilities for ready/loaded on HTMLMediaElement, but the
above would be a good first sweep.

== Avoiding .ready().then() ==

Something we've been discussing as part of ServiceWorker. Should
promise-vending methods with no arguments be allowed to take arguments to
pass onto .then? Eg:

thing.ready().then(onFulfilled, onRejected);
vs
thing.ready(onFulfilled, onRejected);

Both would return a promise, it's just sugar to avoid calling "then".

Happy to take on the spec work for this if there are no objections.

Cheers,
Jake.