- From: Michaela Merz <michaela.merz@hermetos.com>
- Date: Fri, 06 Feb 2015 15:53:21 +0100
- To: Gregg Tracton <tracton@gmail.com>, public-webapps@w3.org
I second Gregg's suggestion. It should be up to the developer to decide whether he wants to block or not. On 02/05/2015 08:58 PM, Gregg Tracton wrote: > I disagree with deprecating synchronous XMLHttpRequest: > > 1) it is not upward compatible & so can break numerous sites. > Many websites do not have active development, and framework updates > that fix this are even slower to roll out to web apps. Many web > app clients would much prefer a sub-optimal experience than a > broken website. > > 2) A better way to approach this might be to respect the async=false > setting but have the browser move the script thread to another thread which > is blocked until the jax (not ajax anymore) completes. Make the browser do > the heavy lifting so scripts remain simple. > > 3) Loading long chains of on-demand content becomes unnecessarily complex. > Example: a config file that specifies URLs for column headers which specify > URLs for content requires 3 nested .success handlers. With async=false, > one can simple write those sequentially. > > 4) Have it been considered if jQuery can create a work-around to simulate > async=false? If not, do not deprecate, as there will be even more > browser-specific code splintering. > > 5) When data loads slowly, many sites will show a "please wait" > view anyway, which disables useful interactions, so how much value > does this deprecation add to usability? > > 6) Do you really want script writers to deal with scroll events while > an ajax is outstanding? That seems to be beyond the ability of a plug-in > to handle in the general case. async=false really simplifies some tasks. > > --Gregg Tracton, Chapel Hill, NC, USA > > > >
Received on Friday, 6 February 2015 14:53:54 UTC