[Bug 28505] Synchronous XHR removal makes patching Error.prepareStackTrace impossible

2016-08-12 Thread bugzilla
Status|NEW |RESOLVED --- Comment #2 from Anne <ann...@annevk.nl> --- If this continuous to be a problem, please contribute to this thread on GitHub: https://github.com/whatwg/xhr/issues/20 Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

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

2016-04-26 Thread Anne van Kesteren
On Mon, Apr 25, 2016 at 8:10 PM, Kirill Dmitrenko <dmi...@yandex-team.ru> 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,

[XHR] null response prop in case of invalid JSON

2016-04-26 Thread Kirill Dmitrenko
Hi! 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 JSON response from a response containing only 'null', which

Re: [XHR]

2016-03-20 Thread Jonas Sicking
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]

2016-03-19 Thread Jonas Sicking
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-03-19 Thread Gomer Thomas
, 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]

2016-03-19 Thread Sangwhan Moon
> 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]

2016-03-19 Thread Gomer Thomas
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]

2016-03-19 Thread Gomer Thomas
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]

2016-03-19 Thread Jonas Sicking
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]

2016-03-19 Thread Domenic Denicola
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]

2016-03-19 Thread Domenic Denicola
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]

2016-03-19 Thread Jonathan Garbee
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]

2016-03-19 Thread Domenic Denicola
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]

2016-03-19 Thread Gomer Thomas
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]

2016-03-19 Thread Elliott Sprehn
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]

2016-03-18 Thread Tab Atkins Jr.
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]

2016-03-18 Thread Gomer Thomas
;; '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]

2016-03-16 Thread Hallvord Reiar Michaelsen Steen
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

[XHR]

2016-03-16 Thread Gomer Thomas
Dear Colleagues, The XHR specification has one very unsatisfactory aspect. It appears that W3C and WHATWG are snubbing your noses at IETF. According to IETF RFC 7230 all HTTP recipients "MUST be able to parse the chunked transfer coding". The logical interpretation of this is tha

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

2015-09-29 Thread Ms2ger
-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

[XHR]

2015-09-25 Thread keeping1740974

=[xhr]

2015-04-28 Thread Ken Nelson
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 as part of a client-side operation. The client-side

Re: =[xhr]

2015-04-28 Thread Tab Atkins Jr.
an override password as part of a client-side operation. The client-side experience could be managed with a sane timeout param - eg return false if no response after X seconds (or ms). Nothing prevents you from waiting on an XHR to return before continuing. Doing it with async operations

=[xhr]

2015-04-23 Thread Charles Perry
This is causing grepolis to lag significantly. Please fix it Charles T Perry

[Bug 28505] New: Synchronous XHR removal makes patching Error.prepareStackTrace impossible

2015-04-17 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28505 Bug ID: 28505 Summary: Synchronous XHR removal makes patching Error.prepareStackTrace impossible Product: WebAppsWG Version: unspecified Hardware: PC OS

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

2015-03-24 Thread Hallvord Reiar Michaelsen Steen
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?

2015-03-23 Thread Hallvord Reiar Michaelsen Steen
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?

2015-03-23 Thread Simon Pieters
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

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

2015-03-23 Thread Simon Pieters
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

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

2015-03-22 Thread Hallvord Reiar Michaelsen Steen
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 charset=UTF-16 in the Content-Type header - should the browser detect the encoding

Re: =[xhr]

2015-01-30 Thread Frederik Braun
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

=[xhr]

2015-01-30 Thread LOUIFI, Bruno
Hi, I am really disappointed when I saw in Chrome debugger that the XMLHttpRequest.open() is deprecating the synchronous mode. This is was the worst news I red since I started working on web applications. I don't know if you release the negative impacts on our professional applications. We

Re: =[xhr]

2014-11-27 Thread Jeffrey Walton
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]

2014-11-24 Thread Domenic Denicola
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]

2014-11-24 Thread Domenic Denicola
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]

2014-11-24 Thread Takeshi Yoshino
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]

2014-11-18 Thread Anne van Kesteren
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]

2014-11-18 Thread Domenic Denicola
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]

2014-11-18 Thread Anne van Kesteren
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]

2014-11-18 Thread Takeshi Yoshino
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]

2014-11-18 Thread 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 us? How would that work? At some point when the browser decides it wants to terminate the fetch

RE: =[xhr]

2014-11-18 Thread Domenic Denicola
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]

2014-11-18 Thread Rui Prior
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: CfC: publish WG Note of XHR Level 2; deadline November 14

2014-11-18 Thread Arthur Barstow
On 11/7/14 11:46 AM, Arthur Barstow wrote: this is a Call for Consensus to: a) Publish a gutted WG Note of the spec (see [Draft-Note]) FYI, this WG Note has been published http://www.w3.org/TR/2014/NOTE-XMLHttpRequest2-20141118/.

=[xhr]

2014-11-17 Thread Rui Prior
AFAIK, there is currently no way of using XMLHttpRequest to make a POST using Transfer-Encoding: Chunked. IMO, this would be a very useful feature for repeatedly sending short messages to a server. You can always make POSTs repeatedly, one per chunk, and arrange for the server to glue the chunks

Re: =[xhr]

2014-11-17 Thread Anne van Kesteren
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]

2014-11-17 Thread Takeshi Yoshino
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]

2014-11-17 Thread Domenic Denicola
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]

2014-11-17 Thread Anne van Kesteren
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]

2014-11-17 Thread Takeshi Yoshino
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]

2014-11-17 Thread Domenic Denicola
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]

2014-11-17 Thread Takeshi Yoshino
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: CfC: publish WG Note of XHR Level 2; deadline November 14

2014-11-08 Thread Domenic Denicola
From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru] That doesn't work with the way W3C manages its work and paper trails. I guess I was just inspired by Mike Smith earlier saying something along the lines of don't let past practice constrain your thinking as to what can be done in

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

2014-11-08 Thread chaals
08.11.2014, 14:46, Domenic Denicola d...@domenic.me: From: cha...@yandex-team.ru [mailto:cha...@yandex-team.ru]  That doesn't work with the way W3C manages its work and paper trails. I guess I was just inspired by Mike Smith earlier saying something along the lines of don't let past practice

CfC: publish WG Note of XHR Level 2; deadline November 14

2014-11-07 Thread Arthur Barstow
During WebApps' XHR discussion on October 27, no one expressed interest to work on XHR L2 [Mins]. The last TR of XHR L2 was published in January 2012 [WD] thus that version should be updated to clarify work has stopped. As such, this is a Call for Consensus to: a) Publish a gutted WG Note

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

2014-11-07 Thread Anne van Kesteren
On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com wrote: https://dvcs.w3.org/hg/xhr/raw-file/default/TR/XHRL2-Note-2014-Nov.html Should this not include a reference to https://xhr.spec.whatwg.org/? -- https://annevankesteren.nl/

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

2014-11-07 Thread Domenic Denicola
On Nov 7, 2014, at 17:55, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com wrote: https://dvcs.w3.org/hg/xhr/raw-file/default/TR/XHRL2-Note-2014-Nov.html Should this not include a reference to https://xhr.spec.whatwg.org

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

2014-11-07 Thread chaals
07.11.2014, 18:28, Domenic Denicola d...@domenic.me:  On Nov 7, 2014, at 17:55, Anne van Kesteren ann...@annevk.nl wrote:  On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com wrote:  https://dvcs.w3.org/hg/xhr/raw-file/default/TR/XHRL2-Note-2014-Nov.html  Should

Re: CfC: publish WG Note of XHR Level 2; deadline November 14

2014-11-07 Thread Arthur Barstow
On 11/7/14 1:05 PM, cha...@yandex-team.ru wrote: 07.11.2014, 18:28, Domenic Denicola d...@domenic.me: On Nov 7, 2014, at 17:55, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Nov 7, 2014 at 5:46 PM, Arthur Barstow art.bars...@gmail.com wrote: https://dvcs.w3.org/hg/xhr/raw-file

[Bug 25090] Use document's encoding for url query encoding in XHR open()

2014-10-27 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25090 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED

WebApps-ACTION-747: Start a cfc to gut xhr l2 and publish a wg note

2014-10-27 Thread Web Applications Working Group Issue Tracker
WebApps-ACTION-747: Start a cfc to gut xhr l2 and publish a wg note http://www.w3.org/2008/webapps/track/actions/747 Assigned to: Arthur Barstow

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

2014-10-24 Thread Arthur Barstow
[ 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 can

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

2014-10-20 Thread Michael[tm] Smith
. XHR in particular seems like a good opportunity for the W3C to reciprocate, since with both specs there's a pretty clear sense that we all want what's best for the web and nobody wants to have their own outdated copy just for the sake of owning it. In that same spirit, I'd suggest that everybody

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

2014-10-20 Thread chaals
or installing a redirection to it. Without the Fetch refactoring, it seems that a new TR based on the old snapshot won't be satisfying the forward compatibility sooner or later. E.g., web authors will also expect an XHR request will fire a fetch event on a service worker, but the old

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

2014-10-20 Thread Anne van Kesteren
On Mon, Oct 20, 2014 at 12:46 PM, cha...@yandex-team.ru wrote: While it seems bleeding edge XHR specs will be in flux for some time (e.g. if Anne takes the spec of record and dismembers it into fetch, I presume he won't get that done within a couple of months...) To be clear, XMLHttpRequest

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

2014-10-20 Thread Arthur Barstow
or REC with a normative reference to a WHATWG spec, the line of logic implied by that statement would be a great way to help achieve that. (Huh? I'm on record for the opposite.) If Hallvord and the other editors of the W3C XHR spec want to reference the Fetch spec, then they should reference

Re: test coverage data for XHR spec

2014-10-20 Thread Anne van Kesteren
On Sun, Oct 19, 2014 at 2:28 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: Here you go, Anne: https://github.com/whatwg/xhr/pull/17 (And I'd guesstimate perhaps half of the meta data is wrong for the WHATWG version of XHR by now - if you want, I can add the text (beta) or something

Re: test coverage data for XHR spec

2014-10-19 Thread Hallvord R. M. Steen
Here you go, Anne: https://github.com/whatwg/xhr/pull/17 (And I'd guesstimate perhaps half of the meta data is wrong for the WHATWG version of XHR by now - if you want, I can add the text (beta) or something like that to the checkbox label). Art: Wondering aloud ... adding this functionality

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

2014-10-19 Thread Arthur Barstow
, 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.. The Plan of Record (PoR) is still to continue to work on both versions of XHR (historically called L1 and L2. However, I agree

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

2014-10-19 Thread Hallvord R. M. Steen
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 http

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

2014-10-19 Thread Michael[tm] Smith
be a great way to help achieve that. If Hallvord and the other editors of the W3C XHR spec want to reference the Fetch spec, then they should reference the Fetch spec. As such, we could do c) but with respect to helping to set realistic expectations for spec that references such a version of XHR, I think

RE: Questions on the future of the XHR spec, W3C snapshot

2014-10-19 Thread Domenic Denicola
to https://domparsing.spec.whatwg.org/ redirected immediately to https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html. This kind of solution seems optimal to me because it removes any potential confusion from the picture. XHR in particular seems like a good opportunity for the W3C to reciprocate

Re: RE: Questions on the future of the XHR spec, W3C snapshot

2014-10-19 Thread 송정기
refactoring, it seems that a new TR based on the old snapshot won't be satisfying the forward compatibility sooner or later. E.g., web authors will also expect an XHR request will fire a fetch event on a service worker, but the old snapshot will still remain with a pointer to a fetch in HTML spec

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

2014-10-18 Thread Tab Atkins Jr.
On Fri, Oct 17, 2014 at 6:05 PM, Domenic Denicola dome...@domenicdenicola.com wrote: No need to make this a vs.; we're all friends here :). FWIW previous specs which have needed to become abandoned because they were superceded by another spec have been re-published as NOTEs pointing to the

Re: test coverage data for XHR spec

2014-10-18 Thread Arthur Barstow
On 10/6/14 7:51 AM, Hallvord R. M. Steen wrote: To test the outcome, load http://www.w3.org/TR/XMLHttpRequest/ and run this from the browser's dev tools' console: document.body.appendChild(document.createElement('script')).src='http://hallvord.com/temp/xhr/annotate_spec.js' You may have

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

2014-10-18 Thread Boris Zbarsky
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: test coverage data for XHR spec

2014-10-17 Thread Hallvord R. M. Steen
I can send you a PR for that JSON file if you wish. For example make a new folder called testcoveragedata or something to put the JSON file inside? If all we need is a single JSON file and maybe a script let's put them in the top-level directory. Should I send you a PR now so you or I can

Re: test coverage data for XHR spec

2014-10-17 Thread Anne van Kesteren
On Fri, Oct 17, 2014 at 10:55 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: Should I send you a PR now so you or I can play our with the linking and styling (I'm very much aware that what the JS currently does to the spec is ugly), or should I wait a few weeks and try to find time to

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

2014-10-17 Thread Hallvord R. M. Steen
to this thread could be to-the-point and avoid the ideological swordmanship as much as possible. When accepting editor positions, we first believed that we could ship a TR of XHR relatively quicky. (I think of that fictive TR as XHR 2 although W3C haven't released any XHR 1, simply because CORS

RE: Questions on the future of the XHR spec, W3C snapshot

2014-10-17 Thread Domenic Denicola
17, 2014 20:19 To: public-webapps Subject: [xhr] Questions on the future of the XHR spec, W3C snapshot Apologies in advance that this thread will deal with something that's more in the realm of politics. First, I'm writing as one of the W3C-appointed editors of the snapshot the WebApps WG

[Bug 27033] New: XHR request termination doesn't terminate queued tasks

2014-10-13 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27033 Bug ID: 27033 Summary: XHR request termination doesn't terminate queued tasks Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW

Re: test coverage data for XHR spec

2014-10-12 Thread Anne van Kesteren
On Sat, Oct 11, 2014 at 7:09 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: I can send you a PR for that JSON file if you wish. For example make a new folder called testcoveragedata or something to put the JSON file inside? If all we need is a single JSON file and maybe a script let's put

Re: test coverage data for XHR spec

2014-10-11 Thread Hallvord R. M. Steen
On Mon, Oct 6, 2014 at 3:04 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: If you do try this on xhr.spec.whatwg.org, you'll see that quite a lot of the meta data is still valid I see. We could make xhr.spec.whatwg.org offer a checkbox that would add these links. That would rock :) We

[Bug 25090] Use document's encoding for url query encoding in XHR open()

2014-10-10 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25090 Bug 25090 depends on bug 23822, which changed state. Bug 23822 Summary: Should the EventSource, Worker, and SharedWorker constructors resolve the URL using utf-8? https://www.w3.org/Bugs/Public/show_bug.cgi?id=23822 What

test coverage data for XHR spec

2014-10-06 Thread Hallvord R. M. Steen
Hi, partly quoting myself from https://github.com/w3c/web-platform-tests/pull/1272 : Nearly all tests in the XHR test suite have (potentially outdated) meta data linking them to specific assertations in the spec. (Technically this is a set of space-separated XPath expressions for each link

Re: test coverage data for XHR spec

2014-10-06 Thread Hallvord R. M. Steen
and adding functionality and all that, but in general the observed behaviour should be mostly stable - right? I hope the tests and assertations are still mostly valid (and if something disagrees with your XHR+Fetch that's probably a bug we'll fix at some point) - the only issue you have should

Re: test coverage data for XHR spec

2014-10-06 Thread Anne van Kesteren
On Mon, Oct 6, 2014 at 3:04 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: If you do try this on xhr.spec.whatwg.org, you'll see that quite a lot of the meta data is still valid - it does add plenty of spec links, while warning in the console about the entries that need updating to match

RE: test coverage data for XHR spec

2014-10-06 Thread Domenic Denicola
Very cool work Hallvord! This is exactly the kind of stuff that we need more of for today's specs, IMO. From: annevankeste...@gmail.com [mailto:annevankeste...@gmail.com] On Behalf Of Anne van Kesteren On Mon, Oct 6, 2014 at 3:04 PM, Hallvord R. M. Steen hst...@mozilla.com wrote: If you do

=[xhr] Expose XMLHttpRequest priority

2014-09-30 Thread Chad Austin
. That is, the API should expose the full set of priorities the browser supports. If my application wants to prioritize an XHR over some browser-initiated request, it should be allowed to do so. The more control over priority available, the better a customer experience can be built. For example, at the logical

Re: =[xhr] Expose XMLHttpRequest priority

2014-09-30 Thread Anne van Kesteren
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

2014-09-30 Thread Chad Austin
things. I recommend contributing there. I don't think we should focus on just XMLHttpRequest. Hi Anne, Thanks for the quick response. Is this something along the lines of a SupportsPriority interface that XHR, various DOM nodes, and such would implement? Can you point me to the existing

Re: =[xhr] Expose XMLHttpRequest priority

2014-09-30 Thread Ilya Grigorik
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. Hi Anne, Thanks for the quick response. Is this something along the lines of a SupportsPriority interface that XHR, various DOM nodes

RE: =[xhr]

2014-09-05 Thread Domenic Denicola
: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]

2014-09-05 Thread Robert Hanson
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]

2014-09-05 Thread James M. Greene
. *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]

2014-09-04 Thread Anne van Kesteren
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

Re: =[xhr]

2014-09-04 Thread Robert Hanson
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]

2014-09-04 Thread James M. Greene
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]

2014-09-04 Thread David Rajchenbach-Teller
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

  1   2   3   4   5   6   7   8   9   10   >