Re: [xhr] responseType for sync requests in window context

I do not think you should be in the business of brute-forcing authors
into converting their applications to use async XHRs. As far as I
understand it, it is the application's UI that may be unresponsive
during a sync XHR. In that case it should be the app. authors choice
which to use. If it is the browser's UI, that is a bug in the browser.

Since this change principally affects WebGL app's it would have been
nice of someone to have mentioned this change in the public-webgl
mailing list while it was still at the proposal stage.

For the record the change has broken all our WebGL applications. Forcing
us to jump through the hoops of using async XHRs is going to have zero
impact on the user experience in our case because the 3D itself is the
UI. Until its loaded there is nothing the user can do.

If sync XHRs are so bad, why to they exist?

Regards

    -Mark