I'm pretty sure you can get rid ofreadyPromise and just usereadyList directly.

Do we want to keep thedocument context? It's another backwards-compatible but non-Promise "feature". And if we do keep it, there should be verifying assertions in test/unit/ready.js.

Perhaps we can leave that subject to change/undocumented. I don't want to verify it if we're going to change it in a future version.

I'm suggesting that we change it now, in both places.

Let's open another ticket then. This PR is already 2 tickets. I'd rather not hold it up. But I'm indifferent as to what context we use here.document still makes sense since it's the document ready handler.

This PR is theintroduction ofjQuery.ready.then... why start off on the wrong foot when we don't have to? It doesn't even make sense to create a ticket referencing behavior that hasn't landed. But I guess I'll put some text here just in case:

PerPromises/A+ andES2015,then callbacks should be called without athis context. And althoughjQuery.Deferred#*With methods provide context to callbacks, we are moving in the direction of increased standards compliance, and should stop providingdocument context tojQuery.ready callbacks while we're already making backwards-incompatible changes tojQuery.ready.

I'm fine with not passingdocument, we just need to document that and the fact that it's async now. I can do that in the release notes once this lands.

@gibson042 The change wouldn't just affectjQuery.ready.then, and I'm familiar with the spec on Promises. Like you said, the document context is for back-compat, as we still have$(function(){}) and$(document).ready(), and while some may preferPromise.resolve(jQuery.ready), I imagine that$(document).ready() and$(function() {}) will still be the most common, and adocument context still makes sense to me on the latter 2. Like I said tho, I'm not opposed to changing that, but we don't have to change it now.

Ok, I can accept that:gh-3026.