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 distinct a > malformed

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 improved with streams. >

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 xhr.responseText to get an ever

RE: [XHR]

, 2016 7:20 PM To: Hallvord R. M. Steen Cc: Gomer Thomas ; WebApps WG Subject: Re: [XHR] Hallvord et al. Le 16 mars 2016 à 20:04, Hallvord Reiar Michaelsen Steen a écrit : > How would you parse for exam

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 *better*, >> so they'll improve "text" response h

Re: [XHR]

Hallvord et al. Le 16 mars 2016 à 20:04, Hallvord Reiar Michaelsen Steen a écrit : > How would you parse for example an incomplete JSON source to expose an > object? Or incomplete XML markup to create a document? Exposing > partial responses for text makes sense - for other types of data > perha

RE: [XHR]

Gomer Thomas Consulting, LLC 9810 132nd St NE Arlington, WA 98223 Cell: 425-309-9933 -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Wednesday, March 16, 2016 1:01 PM To: Gomer Thomas Cc: Hallvord Reiar Mich

RE: [XHR]

9810 132nd St NE Arlington, WA 98223 Cell: 425-309-9933 -Original Message- From: Hallvord Reiar Michaelsen Steen [mailto:hst...@mozilla.com] Sent: Wednesday, March 16, 2016 4:04 AM To: Gomer Thomas Cc: WebApps WG Subject: Re: [XHR] On Tue

Re: [XHR]

, LLC >9810 132nd St NE >Arlington, WA 98223 >Cell: 425-309-9933 > > >-Original Message- > From: Hallvord Reiar Michaelsen Steen [mailto:hst...@mozilla.com] > Sent: Wednesday, March 16, 2016 4:04 AM > To: Gomer Thomas > Cc: WebApp

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 how

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 on

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: > > > According to IETF RFC 7

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 > maj

RE: [XHR]

Consulting, LLC 9810 132nd St NE Arlington, WA 98223 Cell: 425-309-9933 From: Jonathan Garbee [mailto:jonathan.gar...@gmail.com] Sent: Wednesday, March 16, 2016 5:10 AM To: Hallvord Reiar Michaelsen Steen ; Gomer Thomas Cc: WebApps WG Subject: Re: [XHR] If I understand correctly

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 immature and > unders

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 RFC 7230 all HTTP recipients “MUST be able to parse >> > the >> > chunked trans

RE: [XHR]

Cc: 'WebApps WG' Subject: 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 wh

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 the > application as they are r

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 > na

Re: =[xhr]

On Tue, Apr 28, 2015 at 7:51 AM, Ken Nelson 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 an override password

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 r

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

On Mon, 23 Mar 2015 14:32:27 +0100, Hallvord Reiar Michaelsen Steen wrote: On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters 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

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

On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters 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 - should th

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

On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen 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 does *not* send "cha

Re: =[xhr]

Hi, Thank you for your feedback. Please see the archives for previous iterations of this discussion, e.g. (and click "next in thread"). On 29.01.2015 21:04, LOUIFI, Bruno wrote: > Hi, > > I am really disappointed when I

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 b

Re: =[xhr]

On Wed, Nov 19, 2014 at 1:45 AM, Domenic Denicola 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 > wrote: > >> How about padding the remaining bytes forcefully with e.g. 0x20 if

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. Unfortuna

Re: =[xhr]

> I agree this is a nice default. However it should be > overridable for cases where you know the server in > question doesn't support chunked encoding. I am sorry, but I cannot agree. If the server in question does not support chunked encoding (which is part of the standard), it probably will no

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 o

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 me

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 wrote: >> How about padding the remaining bytes forcefully with e.g. 0x20 if the >> WritableStream doesn't provide enough bytes to us? > > How wo

Re: =[xhr]

On Tue, Nov 18, 2014 at 12:50 PM, Takeshi Yoshino 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 (e.g. due to timeout,

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 wrote: > On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola wrote: > > I still think we should just allow the dev

Re: =[xhr]

On Tue, Nov 18, 2014 at 10:34 AM, Domenic Denicola 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). It > gives no

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 5:45 AM, Domenic Denicola 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 through Headers

Re: =[xhr]

On Tue, Nov 18, 2014 at 1:45 PM, Domenic Denicola wrote: > From: Takeshi Yoshino [mailto:tyosh...@google.com] > > > On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren > wrote: > >> On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola wrote: > >>> What do we think of that kind of behavior for fetc

RE: =[xhr]

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

Re: =[xhr]

On Tue, Nov 18, 2014 at 12:11 AM, Anne van Kesteren wrote: > On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola 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. Bei

Re: =[xhr]

On Mon, Nov 17, 2014 at 3:50 PM, Domenic Denicola 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 feature that does n

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 s

Re: =[xhr]

We're adding Streams API 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 sen

Re: =[xhr]

On Fri, Nov 14, 2014 at 7:49 PM, Rui Prior 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 both the request

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: I believe Jungkee will be at the meeting so, Hallvord and Julian please join via the phone bridge and/or IRC if you ca

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 , 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 REC with a normative ref

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

Arthur Barstow , 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 types > of snapsho

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

On Sat, Oct 18, 2014 at 2:19 AM, Hallvord R. M. Steen wrote: > Much of the refactoring work seems to have been just that - refactoring, more > about pulling descriptions of some functionality into another document to > make it more general and usable from other contexts, than about making > cha

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

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

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 t

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 30

Re: =[xhr] Expose XMLHttpRequest priority

On Tue, Sep 30, 2014 at 5:28 AM, Anne van Kesteren wrote: > On Tue, Sep 30, 2014 at 10:25 AM, Chad Austin 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 contributi

Re: =[xhr] Expose XMLHttpRequest priority

On Tue, Sep 30, 2014 at 10:25 AM, Chad Austin 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 XMLHttpRequest. --

Re: =[xhr]

st do Java -> JavaScript that works in browsers. > > > > *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: =[xh

Re: =[xhr]

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

RE: =[xhr]

r 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 of the standard specification that underlies the JavaScript programming language. All modern browsers

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]

Can you send me some reference links? "transpiler"? "ES6 Module"? I realize that what I am doing is pretty wild -- direct implementation of Java in JavaScript -- but it is working so fantastically. Truly a dream come true from a code management point of view. You should check it out. As far as I c

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 hop

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 bett

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]

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 s

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 11:11 PM, Jonas Sicking 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 document environmen

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 2:01 PM, Tab Atkins Jr. wrote: > On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard 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 shou

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 10:49 AM, Anne van Kesteren wrote: > On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson 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 asser

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard 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 telling people

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, 3 Sep 2014, Anne van Kesteren wrote: > On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson 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]

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

Re: {Spam?} Re: [xhr]

On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson 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 http://lists.w3.org/Archives/Public/public-webapps/2

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: =[xhr]

On Wed, Sep 3, 2014 at 8:34 AM, Brendan Eich wrote: > 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

Re: =[xhr]

Indeed, this will be easier to compile, read and debug than CPS but likely slower and more memory-expensive. Note that I am not involved in any DOM-related plans, just answering questions from the original poster that had remained unanswered, based on my personal experience rewriting synchronous c

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: =[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 b

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: {Spam?} Re: {Spam?} Re: [xhr]

Brendan Eich wrote: In this light, WHATWG should avoid making indefinite-timescale, over-ambitious assertions. The W3C was rightly faulted when we founded the WHATWG for doing so. My apologies for a minor error: Anne informs me off-list that "W3C" (who?) added the warning. Not that it should

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]

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 gene

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: {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 j

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 s

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 i

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 so

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]

02.09.2014, 10:55, "Anne van Kesteren" : > On Tue, Sep 2, 2014 at 2:54 AM, Robert Hanson 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 is a document environment

Re: [xhr]

On Tue, Sep 2, 2014 at 2:54 AM, Robert Hanson 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 false for the a

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]

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]

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]

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 http://chemapps.stolaf.edu

Re: =[xhr]

RK and are not appropriate. Simply repeating the mantra over and over is not convincing. From: David Bruant To: nmork_consult...@cusa.canon.com, Cc: Austin William Wright , Glenn Maynard , "Tab Atkins Jr." , public-webapps Date: 08/04/2014 08:07 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 a

Re: =[xhr]

True. From: "James M. Greene" To: nmork_consult...@cusa.canon.com, Cc: Austin William Wright , Glenn Maynard , "Tab Atkins Jr." , public-webapps Date: 08/04/2014 06:44 AM Subject:Re: =[xhr] HOWEVER, I am getting the distinct impression tha

Re: =[xhr]

It's pretty clear to me now that my > request will not be considered. Thank you all for your responses. > > > > From:Austin William Wright > To:Glenn Maynard , > Cc:nmork_consult...@cusa.canon.com, "Ta

Re: =[xhr]

." , public-webapps 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 b

Re: =[xhr]

This is an intranet application. The server is in the next room (locked, of course.) From: David Bruant To: Austin William Wright , Glenn Maynard , Cc: nmork_consult...@cusa.canon.com, "Tab Atkins Jr." , public-webapps Date: 08/02/2014 03:41 AM Subject:

Re: =[xhr]

t;Tab Atkins Jr." , public-webapps Date: 08/02/2014 02:11 AM Subject:Re: =[xhr] On Fri, Aug 1, 2014 at 2:01 PM, Glenn Maynard wrote: On Fri, Aug 1, 2014 at 8:39 AM, wrote: Spinner is not sufficient. All user activity must stop. They can take a coffee break if it takes too long. Br

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

  1   2   3   4   5   6   7   8   9   10   >