On Mon, Nov 1, 2010 at 9:39 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
>>> As long as only one entity is doing the expecting, right? Right now >>> jquery >>> expects to get responseText, so if you expect something else you can't >>> use >>> jquery's XHR wrappers, say.... >> >> I'm not terribly worried about library wrappers. My money is on >> libraries updating faster than browsers are releasing implementations. > > My money is on jquery tip getting updated faster than browsers release > implementations. > > My money is on browsers releasing implementations way faster than websites > are updated to a newer jquery version. > > That, at least, has been our experience with libraries in the past... The > last time jquery made a bogus assumption and then fixed it several months > before a release of ours that would cause breakage due to that assumption it > took heroic efforts over a course of many months by a whole team of people > just to get the top several dozen sites being bitten by the bug to update. > >> I've assumed that all proposals made so far maintain full backwards >> compatibility. So I'm not terribly worried about existing content. Old >> browsers will hold people back much more than old JS libraries. > > I think you're being way too optimistic; see above. So your concern is that jQuery will update to use the new API before browsers implement it. And then once browsers do implement it and start honoring the .responseType by making various existing properties throw, things will fail? This does sound a bit far fetched to me but in any case something that could be solved by communicating with the jQuery devs to not prematurely start using this API. Especially if they're returning the actual XHR object to external code, rather than returning values gotten off of it. / Jonas