2.0.0

[jonathantneal]

Document Promises 2.0.0 would no longer attach properties to the document by default. This would be because no major browsers have yet implemented the behavior, as discussed in #4. Developers may instead import the features individually and use them as they wish.

// Example ES6 import
import contentLoaded from 'document-promises';

// Example CommonJS import
require('document-promises').contentLoaded;

Which might then be used individually.

contentLoaded.then(function () {
  /* document is ready */
});

Or may be used as polyfills at the developer’s own risk.

document.interactive = interactive;
document.contentLoaded = contentLoaded;
document.loaded = loaded;

[jdalton]

I know the r|m regexp bit is a clever minifaction.
However, I've seen regexes go wrong with readyState so maybe explicit is better.

For example MDN states that there's loading, interactive, and complete,
but I think IE may have others like uninitialized and loaded.

[jonathantneal]

I’m fine with that. Would something like /^(interactive|complete)$/ and /^complete$/ be sufficient?

I would hope no-one rejects this polyfill because of the additional 10 gzipped bytes it costs to be explicit. And strangely, /^(complete)$/ costs less.

[jdalton]

Yep, yep.
Something like /^(?:interactive|complete)$/ and /^complete$/ would be great!

[jonathantneal]

See 99d2ecf

[jonathantneal]

@domenic ^

[domenic]

LGTM, thanks <3

[jdalton]

Since we're dealing in unknowns the bit "would be future-incompatible" should prolly be qualified as "could be future-incompatible".

[domenic]

No, "would" is correct in the context of a clause that starts "the standard may still change substantially".

[jdalton]

I donno, maybe things could evolve in a compatible way (it's an unknown after all).