Re: [XHR] null response prop in case of invalid JSON

On Mon, Apr 25, 2016 at 8:10 PM, Kirill Dmitrenko wrote: > I've found in the spec of XHR Level 2 that if a malformed JSON's received > from a server, the response property would be set to null. But null is a > valid JSON, so, if I understand correctly, there is no way to

Re: [XHR]

On Wed, Mar 16, 2016 at 10:29 AM, Tab Atkins Jr. wrote: > No, streams do not solve the problem of "how do you present a > partially-downloaded JSON object". They handle chunked data *better*, > so they'll improve "text" response handling, Also binary handling should be

Re: [XHR]

On Wed, Mar 16, 2016 at 1:54 PM, Gomer Thomas wrote: > but I need a cross-browser solution in the near future Another solution that I think would work cross-browser is to use "text/plain;charset=ISO-8859-15" as content-type. That way I *think* you can simply read

RE: [XHR]

, 2016 7:20 PM To: Hallvord R. M. Steen <hst...@mozilla.com> Cc: Gomer Thomas <go...@gomert-consulting.com>; WebApps WG <public-webapps@w3.org> Subject: Re: [XHR] Hallvord et al. Le 16 mars 2016 à 20:

Re: [XHR]

> On Mar 17, 2016, at 3:12 AM, Jonas Sicking wrote: > >> On Wed, Mar 16, 2016 at 10:29 AM, Tab Atkins Jr. >> wrote: >> No, streams do not solve the problem of "how do you present a >> partially-downloaded JSON object". They handle chunked data

RE: [XHR]

m> Cc: Hallvord Reiar Michaelsen Steen <hst...@mozilla.com>; WebApps WG <public-webapps@w3.org> Subject: Re: [XHR] Sounds like you want access to partial binary data. There's some propitiatory features in Firefox which lets you do this (added ages ago). See [1].

RE: [XHR]

lt;public-webapps@w3.org> Subject: Re: [XHR] On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas <go...@gomert-consulting.com> wrote: > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse > the chunked transfer coding”. Th

Re: [XHR]

Thomas <go...@gomert-consulting.com> > Cc: WebApps WG <public-webapps@w3.org> > Subject: Re: [XHR] > >On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas > <go...@gomert-consulting.com> wrote: > >> According to IETF RFC 7230 all HTTP recip

RE: [XHR]

From: Gomer Thomas [mailto:go...@gomert-consulting.com] > [GT] It would be good to say this in the specification, and > reference > some sample source APIs. (This is an example of what I meant when I said it > is very difficult to read the specification unless one already knows

RE: [XHR]

From: Elliott Sprehn [mailto:espr...@chromium.org] > Can we get an idl definition too? You shouldn't need to read the algorithm to > know the return types. Streams, like promises/maps/sets, are not specced or implemented using the IDL type system. (Regardless, the Web IDL's return types are

Re: [XHR]

If I understand correctly, streams [1] with fetch should solve this use-case. [1] https://streams.spec.whatwg.org/ On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen < hst...@mozilla.com> wrote: > On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas > wrote:

RE: [XHR]

From: Gomer Thomas [mailto:go...@gomert-consulting.com] > I looked at the Streams specification, and it seems pretty immature and > underspecified. I’m not sure it is usable by someone who doesn’t already know > how it is supposed to work before reading the specification. How many of the >

RE: [XHR]

s WG <public-webapps@w3.org> Subject: Re: [XHR] If I understand correctly, streams [1] with fetch should solve this use-case. [1] https://streams.spec.whatwg.org/ On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen <hst...@mozilla.com <mailto:hst...@mozilla.com&g

RE: [XHR]

Can we get an idl definition too? You shouldn't need to read the algorithm to know the return types. On Mar 17, 2016 12:09 PM, "Domenic Denicola" wrote: > From: Gomer Thomas [mailto:go...@gomert-consulting.com] > > > I looked at the Streams specification, and it seems pretty

Re: [XHR]

On Wed, Mar 16, 2016 at 5:10 AM, Jonathan Garbee wrote: > On Wed, Mar 16, 2016 at 7:10 AM Hallvord Reiar Michaelsen Steen > wrote: >> On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas >> wrote: >> >> > According to IETF

RE: [XHR]

;; 'Hallvord Reiar Michaelsen Steen' <hst...@mozilla.com> Cc: 'WebApps WG' <public-webapps@w3.org> Subject: RE: [XHR] From: Gomer Thomas [mailto:go...@gomert-consulting.com] > I looked at the Streams specifi

Re: [XHR]

On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas wrote: > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse the > chunked transfer coding”. The logical interpretation of this is that > whenever possible HTTP recipients should deliver the chunks to

Re: [XHR] Error type when setting request headers.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Yves, On 09/29/2015 03:25 PM, Yves Lafon wrote: > Hi, In XHR [1], setRequestHeader is defined by this: [[ void > setRequestHeader(ByteString name, ByteString value); ]] It has a > note: [[ Throws a SyntaxError exception if name is not a header >

Re: =[xhr]

On Tue, Apr 28, 2015 at 7:51 AM, Ken Nelson k...@pure3interactive.com wrote: RE async: false being deprecated There's still occasionally a need for a call from client javascript back to server and wait on results. Example: an inline call from client javascript to PHP on server to authenticate

Re: [XHR] UTF-16 - do content sniffing or not?

Which MIME type did you use in the response? BOM sniffing in XML is non-normative IIRC. For other types, see below. It's text/plain - seems I definitely need one test with an XML response too.. and one with JSON. [[ If charset is null, set charset to utf-8. Return the result of running

Re: [XHR] UTF-16 - do content sniffing or not?

On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote: On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header -

Re: [XHR] UTF-16 - do content sniffing or not?

On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Hi, I've just added a test loading UTF-16 data with XHR, and it exposes an implementation difference that should probably be discussed: Given a server which sends UTF-16 data with a UTF-16 BOM but

Re: [XHR] UTF-16 - do content sniffing or not?

On Mon, 23 Mar 2015 14:32:27 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote: On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Given a server which sends

Re: =[xhr]

Hi, Thank you for your feedback. Please see the archives for previous iterations of this discussion, e.g. https://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0084.html (and click next in thread). On 29.01.2015 21:04, LOUIFI, Bruno wrote: Hi, I am really disappointed when I saw in

Re: =[xhr]

I think there are several different scenarios under consideration. 1. The author says Content-Length 100, writes 50 bytes, then closes the stream. 2. The author says Content-Length 100, writes 50 bytes, and never closes the stream. 3. The author says Content-Length 100, writes 150 bytes,

RE: =[xhr]

From: Rui Prior [mailto:rpr...@dcc.fc.up.pt] IMO, exposing such degree of (low level) control should be avoided. I disagree on principle :). If we want true webapps we need to not be afraid to give them capabilities (like POSTing data to S3) that native apps have. In cases where the size of

RE: =[xhr]

From: Rui Prior [mailto:rpr...@dcc.fc.up.pt] If you absolutely need to stream content whose length is unknown beforehand to a server not supporting ckunked encoding, construct your web service so that it supports multiple POSTs (or whatever), one per piece of data to upload.

Re: =[xhr]

On Wed, Nov 19, 2014 at 1:45 AM, Domenic Denicola d...@domenic.me wrote: From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino tyosh...@google.com wrote: How about padding the remaining bytes

Re: =[xhr]

On Tue, Nov 18, 2014 at 5:45 AM, Domenic Denicola d...@domenic.me wrote: That would be very sad. There are many servers that will not accept chunked upload (for example Amazon S3). The only way I could imagine us doing this is by setting the Content-Length header value through an option (not

RE: =[xhr]

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren The only way I could imagine us doing this is by setting the Content-Length header value through an option (not through Headers) and by having the browser enforce the specified length somehow.

Re: =[xhr]

On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola d...@domenic.me wrote: I still think we should just allow the developer full control over the Content-Length header if they've taken full control over the contents of the request body (by writing to its stream asynchronously and piecemeal).

Re: =[xhr]

How about padding the remaining bytes forcefully with e.g. 0x20 if the WritableStream doesn't provide enough bytes to us? Takeshi On Tue, Nov 18, 2014 at 7:01 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola d...@domenic.me wrote: I still think

Re: =[xhr]

On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino tyosh...@google.com wrote: How about padding the remaining bytes forcefully with e.g. 0x20 if the WritableStream doesn't provide enough bytes to us? How would that work? At some point when the browser decides it wants to terminate the fetch

RE: =[xhr]

From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino tyosh...@google.com wrote: How about padding the remaining bytes forcefully with e.g. 0x20 if the WritableStream doesn't provide enough bytes to

Re: =[xhr]

I think there are several different scenarios under consideration. 1. The author says Content-Length 100, writes 50 bytes, then closes the stream. Depends on what exactly closing the stream does: (1) Closing the stream includes closing the the TCP connection = the body of the HTTP message

Re: =[xhr]

On Fri, Nov 14, 2014 at 7:49 PM, Rui Prior rpr...@dcc.fc.up.pt wrote: You can always make POSTs repeatedly, one per chunk, and arrange for the server to glue the chunks together, but for short messages this process adds a lot of overhead (a full HTTP request per chunk, with full headers for

Re: =[xhr]

We're adding Streams API https://streams.spec.whatwg.org/ based response body receiving feature to the Fetch API See - https://github.com/slightlyoff/ServiceWorker/issues/452 - https://github.com/yutakahirano/fetch-with-streams Similarly, using WritableStream + Fetch API, we could allow for

RE: =[xhr]

If I recall how Node.js does this, if you don’t provide a `Content-Length` header, it automatically sets `Transfer-Encoding: chunked` the moment you start writing to the body. What do we think of that kind of behavior for fetch requests? My opinion is that it’s pretty convenient, but I am not

Re: =[xhr]

On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we think of that kind of behavior for fetch requests? I'm not sure we want to give a potential hostile piece of script that much control over what goes out. Being able to lie about Content-Length would be a new

Re: =[xhr]

On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we think of that kind of behavior for fetch requests? I'm not sure we want to give a potential hostile piece of script that much

RE: =[xhr]

From: Takeshi Yoshino [mailto:tyosh...@google.com] On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we think of that kind of behavior for fetch requests? I'm not sure we want to give

Re: =[xhr]

On Tue, Nov 18, 2014 at 1:45 PM, Domenic Denicola d...@domenic.me wrote: From: Takeshi Yoshino [mailto:tyosh...@google.com] On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola d...@domenic.me wrote: What do we

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

[ Apologies for top posting ] I just added a 11:30-12:00 time slot on Monday October 27 for XHR: https://www.w3.org/wiki/Webapps/November2014Meeting#Agenda_Monday_October_27 I believe Jungkee will be at the meeting so, Hallvord and Julian please join via the phone bridge and/or IRC if you

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

On 10/19/14 10:02 PM, Michael[tm] Smith wrote: Arthur Barstow art.bars...@gmail.com, 2014-10-19 09:59 -0400: (If someone can show me a PR and/or REC that includes a normative reference to a WHATWG spec, please let me know.) If it's your goal to ensure that we actually do never have a PR or

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

On 10/17/14 8:19 PM, Hallvord R. M. Steen wrote: I'd appreciate if those who consider responding to this thread could be to-the-point and avoid the ideological swordmanship as much as possible. I would appreciate that too (and I will endeavor to moderate replies accordingly.) However, the

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

However, the WHATWG version is now quite heavily refactored to be XHR+Fetch. It's no longer clear to me whether pushing forward to ship XHR2 stand-alone is the right thing to do.. (For those not familiar with WebApps' XHR TR publication history, the latest snapshots are: Level1

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

Arthur Barstow art.bars...@gmail.com, 2014-10-19 09:59 -0400: ... c) Ship a TR based on the newest WHATWG version, reference WHATWG's Fetch spec throughout. The staff does indeed permit normative references to WHATWG specs in WD and CR publications so that wouldn't be an issue for those

Re: [xhr] Questions on the future of the XHR spec, W3C snapshot

On 10/17/14, 8:19 PM, Hallvord R. M. Steen wrote: a) Ship a TR based on the spec just *before* the big Fetch refactoring. If we want to publish something at all, I think this is the most reasonable option, frankly. I have no strong opinions on whether this is done REC-track or as a Note, I

Re: =[xhr] Expose XMLHttpRequest priority

On Tue, Sep 30, 2014 at 10:25 AM, Chad Austin caus...@gmail.com wrote: What will it take to get this added to the spec? There's been a pretty long debate on the WHATWG mailing list how to prioritize fetches of all things. I recommend contributing there. I don't think we should focus on just

Re: =[xhr] Expose XMLHttpRequest priority

On Tue, Sep 30, 2014 at 5:28 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Sep 30, 2014 at 10:25 AM, Chad Austin caus...@gmail.com wrote: What will it take to get this added to the spec? There's been a pretty long debate on the WHATWG mailing list how to prioritize fetches of all

Re: =[xhr] Expose XMLHttpRequest priority

http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0081.html - I recently got some good offline feedback on the proposal, need to update it, stay tuned. http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0177.html - related~ish, may be of interest. ig On Tue, Sep

RE: =[xhr]

:09 To: Robert Hanson Cc: David Rajchenbach-Teller; public-webapps; Greeves, Nick; Olli Pettay Subject: Re: =[xhr] ES6 is short for ECMAScript, 6th Edition, which is the next version of the standard specification that underlies the JavaScript programming language. All modern browsers currently

Re: =[xhr]

Java - JavaScript that works totally asynchronously is the plan. Should have that working relatively soon. jmolScript here x = load(file00+ (++i) + .pdb) /jmolScript here but we can live with that. Bob Hanson ​

Re: =[xhr]

. *From:* James M. Greene [mailto:james.m.gre...@gmail.com] *Sent:* Friday, September 5, 2014 05:09 *To:* Robert Hanson *Cc:* David Rajchenbach-Teller; public-webapps; Greeves, Nick; Olli Pettay *Subject:* Re: =[xhr] ES6 is short for ECMAScript, 6th Edition, which is the next version

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 11:11 PM, Jonas Sicking jo...@sicking.cc wrote: Agreed. Making it a conformance requirement not to use sync XHR seems like a good idea. It is a conformance requirement. Developers must not pass false for the async argument when the JavaScript global environment is a

Re: =[xhr]

SO glad to hear that. I expect to have a fully asynchronous version of JSmol available for testing soon. It will require some retooling of sophisticated sites, but nothing that a typical JavaScript developer of pages utilizing JSmol cannot handle. I still have issues with the language in the w3c

Re: =[xhr]

The sole reason for these sync XHRs, if you recall the OP, is to pull in libraries that are only referenced deep in a call stack, so as to avoid having to include *all* the libraries in the initial download. If that is true, wouldn't it better for him to switch over to ES6 Module imports and

Re: =[xhr]

On 04/09/14 14:31, James M. Greene wrote: The sole reason for these sync XHRs, if you recall the OP, is to pull in libraries that are only referenced deep in a call stack, so as to avoid having to include *all* the libraries in the initial download. If that is true, wouldn't it better for

Re: =[xhr]

True that ES6 Modules are not quite ready yet but the existing transpilers for it also convert to asynchronously loading AMD syntax, a la RequireJS. Still seems a perfect fit for this use case, and Robert may not be aware that such functionality is forthcoming to solve his issue (and obviously

Re: =[xhr]

ES6 is short for ECMAScript, 6th Edition, which is the next version of the standard specification that underlies the JavaScript programming language. All modern browsers currently support ES5 (ECMAScript, 5th Edition) and some parts of ES6. IE7-8 supported ES3 (ES4 was rejected, so supporting ES3

Re: =[xhr]

I would like to emphasise the detrimental effect that the proposed experimentation would have on a large number of sites across Chemistry research and education that would mysteriously stop working when users (automatically) upgraded their browsers and JSmol ceased to function. JSmol is used

Re: =[xhr]

Yes, sure, a lot of it can be done asynchronously. And I do that as much as possible. But I suggest there are times where synchronous transfer is both appropriate and necessary. The case in point is 50 levels deep in the stack of function calls when a new Java class is needed. This statement is

Re: {Spam?} Re: [xhr]

On 9/2/14 9:10 PM, Brendan Eich wrote: cha...@yandex-team.ru wrote: Sorry. As with showModalDialog() we would really like to make this feature disappear. I realize this makes some forms of code generation harder, but hopefully you can find a way around that in time. Perhaps we should

Re: {Spam?} Re: [xhr]

That I think what is unclear from the writing of the warning are two things: 1) It *appears *to be part of the spec. (The parts before say they are non-normative, but this section does not.) And it uses the word must -- implying that it is a requirement, not a recommendation. 2) Perhaps it is

Re: =[xhr]

On 09/03/2014 12:10 PM, Greeves, Nick wrote: I would like to emphasise the detrimental effect that the proposed experimentation would have on a large number of sites across Chemistry research and education that would mysteriously stop working when users (automatically) upgraded their browsers

Re: =[xhr]

Q1) No, there is no immediate alternative at the moment, nor is there one planned. One of the reasons for this proposed change to the semantics of XHR is to stop hiding asynchronous behavior behind a synchronous implementation that cannot be quite implemented in a satisfactory manner. Q2) The

Re: =[xhr]

Olli, Thanks for the reassurance and your comment about nightly builds makes a lot of sense. Users of those would expect things to break. All the best Nick -- 3D Organic Animations http://www.chemtube3d.com Tel: +44 (0)151-794-3506 (3500 secretary) On 3 Sep 2014, at 13:57, Olli

Re: =[xhr]

David Rajchenbach-Teller wrote: it would require changes to Java2Script. Big changes -- CPS conversion, compiling with continuations. This would require identifying all the potential blocking points. It's not clear anyone will do it, even if it is feasible (thanks to Java's static types and

Re: =[xhr]

David Rajchenbach-Teller wrote: Clearly, it would require big changes, although compiling to return Promise and using Task.js + yield at call sites would probably be much simpler than CPS conversion. All call sites, every last Java method = JS function call? That means every single function

Re: =[xhr]

On 03/09/14 17:27, Brendan Eich wrote: David Rajchenbach-Teller wrote: it would require changes to Java2Script. Big changes -- CPS conversion, compiling with continuations. Clearly, it would require big changes, although compiling to return Promise and using Task.js + yield at call sites

Re: {Spam?} Re: [xhr]

On Tue, 2 Sep 2014, Brendan Eich wrote: Also (I am a WHATWG cofounder) it is overreach to promise obsolescence on any timeline on the Web. Robert should not worry about real browser implementors breaking content by removing sync XHR -- to do so would be to lose market share. In this

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion. See

Re: {Spam?} Re: [xhr]

On 9/3/14 8:25 AM, Robert Hanson wrote: That I think what is unclear from the writing of the warning are two things: Per the specs' Participate boilerplate, perhaps you should file a bug (^1). -Thanks, AB ^1 https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWGcomponent=XHR

Re: {Spam?} Re: [xhr]

On Wed, 3 Sep 2014, Anne van Kesteren wrote: On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion.

Re: {Spam?} Re: [xhr]

(Branden, your mails keep getting {Spam?} put in the header, which means every time you post, you create a new thread for Gmail users. I guess it's the list software to blame for changing subject lines, but it's making a mess of this thread...) On Wed, Sep 3, 2014 at 12:49 PM, Anne van Kesteren

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard gl...@zewt.org wrote: My only issue is the wording: it doesn't make sense to have normative language saying you must not use this feature. This should be a non-normative note warning that this shouldn't be used, not a normative requirement

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 10:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 2:01 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard gl...@zewt.org wrote: My only issue is the wording: it doesn't make sense to have normative language saying you must not use this feature. This should be a non-normative

Re: [xhr]

On Tue, Sep 2, 2014 at 2:54 AM, Robert Hanson hans...@stolaf.edu wrote: I respectively request that the wording of the warning on the pages https://dvcs.w3.org/hg/xhr/raw-file/default/xhr-1/Overview.html and http://xhr.spec.whatwg.org/ be changed from Warning: Developers must not pass

Re: [xhr]

02.09.2014, 10:55, Anne van Kesteren ann...@annevk.nl: On Tue, Sep 2, 2014 at 2:54 AM, Robert Hanson hans...@stolaf.edu wrote:  I respectively request that the wording of the warning [...]  Warning: Developers must not pass false for the async argument when the  JavaScript global environment

Re: {Spam?} Re: [xhr]

cha...@yandex-team.ru wrote: Sorry. As with showModalDialog() we would really like to make this feature disappear. I realize this makes some forms of code generation harder, but hopefully you can find a way around that in time. Perhaps we should set some sense of expectation about*when*

Re: =[xhr]

To: Ms. Anne Kesteren, Editor, and associates [more specific request than above] I respectfully request that the warning on page http://xhr.spec.whatwg.org/ Warning: Developers must not pass false for the async argument when the JavaScript global environment

Re: =[xhr]

Thank you for the quick reply. I have been traveling and just noticed it. I think you misunderstand. If you want to see what I have, take a look at any of the demos in http://chemapps.stolaf.edu/jmol/jsmol, in particular http://chemapps.stolaf.edu/jmol/jsmol/jsmol.htm or

Re: =[xhr]

I would suggest taking a look at what you can do with Generators and Promises in ES6 for example ( https://www.npmjs.org/package/co ) or if you want to try something from ES7 async functions https://github.com/lukehoban/ecmascript-asyncawait I work on applications of over 200,000K LOC and we load

Re: =[xhr]

I work on applications of over 200,000K LOC and we load everything in one go, are you bundling and gzipping your source? Minifying? 150,000 LOC doesn't seem to require this complexity. We must be talking about two different things. Yes, the bulk of the code is minified. It is still several

Re: =[xhr]

...@cusa.canon.com, Tab Atkins Jr. jackalm...@gmail.com, public-webapps public-webapps@w3.org Date: 08/02/2014 02:11 AM Subject:Re: =[xhr] On Fri, Aug 1, 2014 at 2:01 PM, Glenn Maynard gl...@zewt.org wrote: On Fri, Aug 1, 2014 at 8:39 AM, nmork_consult...@cusa.canon.com wrote: Spinner

Re: =[xhr]

-webapps public-webapps@w3.org Date: 08/02/2014 03:41 AM Subject:Re: =[xhr] Le 02/08/2014 11:11, Austin William Wright a écrit : Maybe there's another reason: Good idea or no, removing this feature DOES break reverse compatibility with the de-facto behavior of many Web browsers. Everyone

Re: =[xhr]

...@cusa.canon.com, Tab Atkins Jr. jackalm...@gmail.com, public-webapps public-webapps@w3.org Date: 08/02/2014 03:41 AM Subject:Re: =[xhr] Le 02/08/2014 11:11, Austin William Wright a écrit : Maybe there's another reason: Good idea or no, removing this feature DOES break reverse compatibility

Re: =[xhr]

for your responses. From:Austin William Wright a...@bzfx.net To:Glenn Maynard gl...@zewt.org, Cc:nmork_consult...@cusa.canon.com, Tab Atkins Jr. jackalm...@gmail.com, public-webapps public-webapps@w3.org Date:08/02/2014 02:11 AM Subject:Re: =[xhr

Re: =[xhr]

True. From: James M. Greene james.m.gre...@gmail.com To: nmork_consult...@cusa.canon.com, Cc: Austin William Wright a...@bzfx.net, Glenn Maynard gl...@zewt.org, Tab Atkins Jr. jackalm...@gmail.com, public-webapps public-webapps@w3.org Date: 08/04/2014 06:44 AM Subject:Re

Re: =[xhr]

Le 04/08/2014 15:30, nmork_consult...@cusa.canon.com a écrit : This is an intranet application. The server is in the next room (locked, of course.) I was seeing this one coming when I wrote my paragraph :-p If you're in a tightly controlled environment, one could question the choice of a web

Re: =[xhr]

public-webapps@w3.org Date: 08/04/2014 08:07 AM Subject:Re: =[xhr] Le 04/08/2014 15:30, nmork_consult...@cusa.canon.com a écrit : This is an intranet application. The server is in the next room (locked, of course.) I was seeing this one coming when I wrote my paragraph :-p If you're

Re: =[xhr]

On Fri, Aug 1, 2014 at 2:01 PM, Glenn Maynard gl...@zewt.org wrote: On Fri, Aug 1, 2014 at 8:39 AM, nmork_consult...@cusa.canon.com wrote: Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Browser must be frozen and locked down

Re: =[xhr]

Le 02/08/2014 11:11, Austin William Wright a écrit : Maybe there's another reason: Good idea or no, removing this feature DOES break reverse compatibility with the de-facto behavior of many Web browsers. Everyone who wants sync xhr to disappear is well-aware. That's the reason it hasn't been

Re: =[xhr]

...@cusa.canon.com, Cc: public-webapps public-webapps@w3.org Date: 07/31/2014 03:47 PM Subject:Re: =[xhr] On Tue, Jul 29, 2014 at 1:41 PM, nmork_consult...@cusa.canon.com wrote: While debugging an intranet application using xmlHttpRequest recently, I got a message on the Firefox

Re: =[xhr]

On Aug 1, 2014 8:16 AM, nmork_consult...@cusa.canon.com wrote: In this case, a freeze on all browser operations is desirable. The thread cannot be interrupted, and if it is interrupted (by browser closure or other such) then the transactions are immediately stopped and no update will occur

Re: =[xhr]

. jackalm...@gmail.com To: nmork_consult...@cusa.canon.com, Cc: public-webapps public-webapps@w3.org Date: 08/01/2014 06:33 AM Subject:Re: =[xhr] On Aug 1, 2014 8:16 AM, nmork_consult...@cusa.canon.com wrote: In this case, a freeze on all browser operations is desirable

Re: =[xhr]

On Aug 1, 2014 8:39 AM, nmork_consult...@cusa.canon.com wrote: Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Browser must be frozen and locked down completely. No other options are desirable. All tabs, menus, etc. must be frozen.

Re: =[xhr]

Thank you for letting me know my input is not desired. From: Tab Atkins Jr. jackalm...@gmail.com To: nmork_consult...@cusa.canon.com, Cc: public-webapps public-webapps@w3.org Date: 08/01/2014 06:46 AM Subject:Re: =[xhr] On Aug 1, 2014 8:39 AM, nmork_consult

Re: =[xhr]

, and it's less hostile. How is this unreasonable? From:Tab Atkins Jr. jackalm...@gmail.com To:nmork_consult...@cusa.canon.com, Cc:public-webapps public-webapps@w3.org Date:08/01/2014 06:46 AM Subject:Re: =[xhr] On Aug

  1   2   3   4   5   6   7   8   9   >