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 is a

Re: File API: reading a Blob

2014-09-04 Thread Aymeric Vitte
Arun, I know you (File API) care about it, I was more refering to other groups that seem not to care a lot, leading to absurd situations where we are streaming things without streams and have to implement some strange inadapted mechanisms for flow control/backpressure for example. The

Re: File API: reading a Blob

2014-09-04 Thread Anne van Kesteren
On Thu, Sep 4, 2014 at 12:02 AM, Aymeric Vitte vitteayme...@gmail.com wrote: Sorry to interfer then but your discussion with Arun seems to have no point if streams are there. I don't follow. The fact is that most of the W3C groups impacted by streams (File, indexedDB, MSE, WebRTC,

Re: Proposal for a Permissions API

2014-09-04 Thread Mounir Lamouri
On Thu, 4 Sep 2014, at 01:33, Kostiainen, Anssi wrote: Given there's good discussion going on at the Paris meeting right now [4] and the topic is on the agenda, I’m expecting more input from the meeting participants on how to proceed. Could you share here the outcome of that discussion if not

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

[admin] Revised Proposed changes regarding references to editors' drafts

2014-09-04 Thread Arthur Barstow
FYI, below is an updated proposal for TR Publication Rules regarding references to EDs and the boilerplate at the top of a document. If you have any feedback on this proposal, please send it to spec-prod @ w3.org http://lists.w3.org/Archives/Public/spec-prod/. Original Message

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

[admin] Towards making ED boilerplates more useful and consistency

2014-09-04 Thread Arthur Barstow
Hi Editors, All, Speaking of ED boilerplate data ... do we want to try to get some consistency regarding boilerplate data in our EDs? We have quite a bit of variation now. For example Clipboard and others are toward the more minimalist end of the spectrum:

Re: PFWG request for abstract and introductions

2014-09-04 Thread Arthur Barstow
Hi Michael, All, Thanks for your e-mail. I'm _really_ sorry for the delayed reply [this email was accidentally moved to my Back Burner folder where I just noticed it)! Although I will check all of WebApps' specs and ask Editors to update their documents accordingly, are there any specs that

Re: =[xhr]

2014-09-04 Thread James M. Greene
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: Proposal for a Permissions API

2014-09-04 Thread Kostiainen, Anssi
On 04 Sep 2014, at 13:48, Mounir Lamouri mou...@lamouri.fr wrote: On Thu, 4 Sep 2014, at 01:33, Kostiainen, Anssi wrote: Given there's good discussion going on at the Paris meeting right now [4] and the topic is on the agenda, I’m expecting more input from the meeting participants on how to

Re: [admin] Towards making ED boilerplates more useful and consistency

2014-09-04 Thread Tab Atkins Jr.
On Thu, Sep 4, 2014 at 5:43 AM, Arthur Barstow art.bars...@gmail.com wrote: Hi Editors, All, Speaking of ED boilerplate data ... do we want to try to get some consistency regarding boilerplate data in our EDs? We have quite a bit of variation now. For example Clipboard and others are toward

Re: Proposal for a Permissions API

2014-09-04 Thread Edward O'Connor
Hi, Mounir wrote: Permissions API would be a single entry point for a web page to check if using API /foo/ would prompt, succeed or fail. It would be a mistake to add such an API to the platform. A unified API for explicit permissioning is an attractive nuisance which future spec authors will

Re: Proposal for a Permissions API

2014-09-04 Thread Kis, Zoltan
Hello, On Thu, Sep 4, 2014 at 8:23 PM, Edward O'Connor eocon...@apple.com wrote: Mounir wrote: Permissions API would be a single entry point for a web page to check if using API /foo/ would prompt, succeed or fail. It would be a mistake to add such an API to the platform. A unified API for

Re: Proposal for a Permissions API

2014-09-04 Thread Florian Bösch
This is an issue to use, for a user. - http://codeflow.org/issues/permissions.html - http://codeflow.org/issues/permissions.jpg - In firefox it's a succession of popup It's also an issue to use for a developer, because the semantics and methods for requesting, getting, being denied and

Re: Proposal for a Permissions API

2014-09-04 Thread Marcos Caceres
On September 4, 2014 at 4:14:57 PM, Florian Bösch (pya...@gmail.com) wrote: This is an issue to use, for a user. - http://codeflow.org/issues/permissions.html - http://codeflow.org/issues/permissions.jpg This sets up an unrealistic straw-man. Are there any real sites that would need to

Re: Proposal for a Permissions API

2014-09-04 Thread Florian Bösch
On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres mar...@marcosc.com wrote: This sets up an unrealistic straw-man. Are there any real sites that would need to show all of the above all at the same time? Let's say you're writing a video editor, you'd like: - To get access to the locations API

Re: Proposal for a Permissions API

2014-09-04 Thread Marcos Caceres
-- Marcos Caceres On September 4, 2014 at 4:24:56 PM, Florian Bösch (pya...@gmail.com) wrote: On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres wrote: This sets up an unrealistic straw-man. Are there any real sites that would need to show all of the above all at the same time?

Re: Proposal for a Permissions API

2014-09-04 Thread Jeffrey Walton
On Thu, Sep 4, 2014 at 4:24 PM, Florian Bösch pya...@gmail.com wrote: On Thu, Sep 4, 2014 at 10:18 PM, Marcos Caceres mar...@marcosc.com wrote: This sets up an unrealistic straw-man. Are there any real sites that would need to show all of the above all at the same time? Let's say you're

Re: XMLHttpRequest. Support for OPTIONS * method.

2014-09-04 Thread Anne van Kesteren
On Thu, Sep 4, 2014 at 8:32 PM, Валерий Котов kotov.val...@gmail.com wrote: Could you please tell if it is possible to send OPTIONS * http request by using XMLHttpRequest class? That is not supported. I suspect adding support for it might create a security vulnerability for servers as it is not

Re: XMLHttpRequest. Support for OPTIONS * method.

2014-09-04 Thread Mark Nottingham
Huh? OPTIONS * isn’t exactly common, but it’s very much OK by HTTP… On 4 Sep 2014, at 11:47 pm, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Sep 4, 2014 at 8:32 PM, Валерий Котов kotov.val...@gmail.com wrote: Could you please tell if it is possible to send OPTIONS * http request by

Re: Proposal for a Permissions API

2014-09-04 Thread Vincent Scheib
On Thu, Sep 4, 2014 at 1:50 PM, Florian Bösch pya...@gmail.com wrote: Well, the motivation to ask for permission up front is so that you later don't have to pester the user. Everytime you poll a user, there's a possibility he'll not see the prompt (happens to me pretty frequently in chrome

Re: =[xhr]

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