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 document environment as it has detrimental effects to the end user's experience. -- http://annevankesteren.nl/
Re: File API: reading a Blob
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 examples I gave in this thread are just a small subset of what I (everybody) need, which involves all the groups listed below. Despite of the fact that the spec is probably mature enough, I am not sure it can really be finalized without parallel field experimentation, which to work well needs to involve several groups and browsers from now, despite of the efforts of people involved the process is really too long. If we take the File API to address your concern, probably the question is not whether the earlier (or whatever) version should be modified (because the answer would be obviously yes for me, use cases are legion) but to make it work on the field with streams and finalize the spec accordingly, same thing for the other APIs. Regards, Aymeric Le 04/09/2014 02:39, Arun Ranganathan a écrit : On Sep 3, 2014, at 6:02 PM, Aymeric Vitte vitteayme...@gmail.com mailto:vitteayme...@gmail.com wrote: The fact is that most of the W3C groups impacted by streams (File, indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream, etc, I must forget a lot here) seem not to care a lot about it and maybe just expect streams to land in the right place in the APIs when they are available, by some unknown magic. I care about it. Till the API is totally baked, I’m amenable to getting the model right. File API now refers to chunks read, which is more correct. But I understand that your use cases aren’t catered to just yet; FileReader/FileReaderSync don’t do easily extractable partials. I’d like to see if there’s interest in the earlier proposal, to extract a stream straight from Blob. I still think that the effort should start from now for all the APIs (as well as the implementation inside browsers, which apparently has started for Chrome, but Chrome was supposed to have started some implementation of the previous Streams APIs, so it's not very clear), and that it should be very clearly synchronized, disregarding vague assumptions from the groups about low/high level and Vx releases, eluding the issue. What issue is being eluded? Seems like another of your main use cases is to have URL.createObjectURL or URL.createFor return a streamable resource. I agree that’s a good problem to solve. — A* -- Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
Re: File API: reading a Blob
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, WebCrypto, Workers, XHR, WebSockets, Media Stream, etc, I must forget a lot here) seem not to care a lot about it and maybe just expect streams to land in the right place in the APIs when they are available, by some unknown magic. Well, we need to sort out the fundamental abstraction first and that is taking its time. Only then can we integrate it throughout the system. I still think that the effort should start from now for all the APIs (as well as the implementation inside browsers, which apparently has started for Chrome, but Chrome was supposed to have started some implementation of the previous Streams APIs, so it's not very clear), and that it should be very clearly synchronized, disregarding vague assumptions from the groups about low/high level and Vx releases, eluding the issue. Well, we are looking into it from an API perspective. Perhaps not all, but we have had quite a bit of discussion (elsewhere, not here) how streams should work with the new fetch() method. But again, I think as with promises, we need the primitive first. -- http://annevankesteren.nl/
Re: Proposal for a Permissions API
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 the minutes? Thanks, -- Mounir
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 spec, but I am much relieved. Bob Hanson
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 an appropriate transpiler, for now? I'm a bit confused as to why it doesn't appear this idea was ever mentioned. Sincerely, James Greene Sent from my [smart?]phone On Sep 4, 2014 7:19 AM, Robert Hanson hans...@stolaf.edu wrote: 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 spec, but I am much relieved. Bob Hanson
[admin] Revised Proposed changes regarding references to editors' drafts
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 Subject: [Pubrules] Revised Proposed changes regarding references to editors' drafts Date: Wed, 3 Sep 2014 12:13:48 -0500 From: Ian Jacobs i...@w3.org To: spec-p...@w3.org Prod spec-p...@w3.org CC: Arthur Barstow art.bars...@gmail.com, Marcos Caceres w...@marcosc.com Hello spec-prod, Several months ago I send a list of proposed changes [1] regarding references to editors' drafts from W3C specs. I received some feedback and have revised the proposal (below). Here is an updated proposal. After the proposal are my notes on how I handled the previous feedback, and changes to the proposal as a result. I apologize for the delay in updating the proposal. Ian [1] http://lists.w3.org/Archives/Public/spec-prod/2014AprJun/0001.html == Goals * Provide appropriate statements about relationships between a TR draft and an editor's draft. * Ensure clarity about editors and ensure they are given credit. * Avoid publication delays. * Reduce chances publication requests will be declined due to references to editors' drafts. = Proposed Guidance * Editor names. In each document (TR draft and editor's draft) indicate clearly who is editing the document. The list of editors MAY differ between the documents. Notes: - The process requires at least one editor: Every Technical Report published as part of the Technical Report development process is edited by one or more editors appointed by a Group Chair. The Process CG is the appropriate forum for discussing that requirement. - Pubrules already allows additional information about authors and contributors; here's an example: http://www.w3.org/TR/UAAG10/ - For TRs, the Process requires An editor must be a participant. While it is possible for an editor of an editor's draft to not participate in a W3C group, it is important to understand any patent policy implications. * The Marcomm team seeks to balance editor innovation, application of W3C process and patent policy requirements, and consistency and usefulness for readers. To avoid delays after a publication request: - Editors who wish to add features to the top of a W3C technical report beyond those described in the pubrules templates SHOULD consult with the Marcomm Team in advance. - Team contacts who observe consensus within a WG to publish a FPWD SHOULD contact the W3C Communications Team to begin to coordinate the publication. * Here is RECOMMENDED language for references to an editor's draft (for example, from a dismissable popup designed to attract the reader's attention). - For a Working Draft: Implementors should be aware that this specification is not stable and may change in ways incompatible with existing implementations. All implementers are invited to take part in group discussion. This draft captures the state of the specification as of the publication date. The aeditor's draft/a may include bug fixes and other changes. - For a Candidate Recommendation: Implementors should be aware that the feature set for this specification is stable, although the details of those features may still change. All implementers are invited to take part in group discussion. This draft captures the state of the specification as of the publication date. The aeditor's draft/a may include bug fixes and other changes. - For a Recommendation: Implementors should be aware that this is a stable specification suitable for implementation; please check to see if there are any aerrata/a. For information about new developments related to this specification, see asuitable reference/a. Proposed Additions to Pubrules * Document titles/subtitles MUST NOT include status information or otherwise create confusion. For example the document title must not include status indicators such as draft or recommendation or standard. Note: The subhead includes the status and publication date. Note on checker test: we can look for some common phrases but the check won't be exhaustive. * The document MAY include a link to an Editor's Draft. That link MAY precede the other document identifiers. The label for this link should be Editor's Draft. * A document MAY include, near the top, guidance for providing feedback. Any such block MUST follow the Editors block. The recommended title for this block is Feedback? Note on checker test: look for feedback block and verify position. * Departures from pubrules expectations for the top of a W3C technical report, or text in the status section that may cause
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 him to switch over to ES6 Module imports and an appropriate transpiler, for now? I'm a bit confused as to why it doesn't appear this idea was ever mentioned. I believe it's simply because ES6 Modules are not fully implemented in browsers yet. But yes, with the timescale discussed, I agree that ES6 Modules are certainly the best long-term choice for this specific use case. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature
[admin] Towards making ED boilerplates more useful and consistency
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: http://dev.w3.org/2006/webapi/clipops/clipops.html Whereas, the Manifest spec's boilerplate data is more thorough: http://w3c.github.io/manifest/ I personally prefer the Manifest approach (especially a link to the spec's bugs/issues and the comment list). Should we try to get more consistency, and if so, what data should be the minimal recommended set? -Thanks, AB
Re: PFWG request for abstract and introductions
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 are of high/keen interest to you? (WebApps' spec list is https://www.w3.org/2008/webapps/wiki/PubStatus.) -Thanks, ArtB On 6/20/14 10:33 AM, Michael Cooper wrote: The WAI Protocols and Formats Working Group has looked at a number of specifications published by the Web Applications Working Group recently. Our process is to note the publication of documents and take a quick look to determine if they need a closer review. However, many of the documents we have looked at recently have extremely brief abstracts, and no introductions. This makes it very difficult for us to figure out the nature of the specification, and in turn to determine what our interest in it might be. We request that you add more complete abstracts to the specifications, to provide a high-level but more complete idea of what the specification does. We also request that you add introduction sections to the specifications, to explain what problem the technology solves and how (in general terms) it addresses that. We think this will aid our own review and will also greatly help other reviewers to make useful comments. Michael Cooper PFWG staff contact
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 hopefully is delivered long before sync XHRs become volatile). Sincerely, James Greene Sent from my [smart?]phone On Sep 4, 2014 7:42 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: 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 him to switch over to ES6 Module imports and an appropriate transpiler, for now? I'm a bit confused as to why it doesn't appear this idea was ever mentioned. I believe it's simply because ES6 Modules are not fully implemented in browsers yet. But yes, with the timescale discussed, I agree that ES6 Modules are certainly the best long-term choice for this specific use case. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla
Re: Proposal for a Permissions API
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 proceed. Could you share here the outcome of that discussion if not the minutes? Sure, here are the meeting minutes (search for “Permissions API”): https://docs.google.com/document/d/1sPNHXRy7tkj0F2gdTtRHj9oFRNhQkaQy2A9t-JnSvsU/preview Please note this is truly a living document as it is still being edited. I expect a stable version of the minutes to be released later. Thanks, -Anssi
Re: [admin] Towards making ED boilerplates more useful and consistency
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 the more minimalist end of the spectrum: http://dev.w3.org/2006/webapi/clipops/clipops.html Whereas, the Manifest spec's boilerplate data is more thorough: http://w3c.github.io/manifest/ I personally prefer the Manifest approach (especially a link to the spec's bugs/issues and the comment list). Should we try to get more consistency, and if so, what data should be the minimal recommended set? We've found in the CSSWG that linking to issue tracking is indeed helpful, when the spec uses anything more than email and inline issues. We also provide feedback information: see Color http://dev.w3.org/csswg/css-color/ for one example. ~TJ
Re: Proposal for a Permissions API
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 be drawn to. We should be avoiding adding features to the platform that have to resort to explicit permissioning. Instead of adding features which require prompting for permission, we should be designing features—like drag drop or input type=file—that don't require prompting for permission at all. I don't think much has changed since this last came up, in the context of Notifications: http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0029.html Ted
Re: Proposal for a Permissions API
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 explicit permissioning is an attractive nuisance which future spec authors will be drawn to. We should be avoiding adding features to the platform that have to resort to explicit permissioning. Instead of adding features which require prompting for permission, we should be designing features—like drag drop or input type=file—that don't require prompting for permission at all. I don't think much has changed since this last came up, in the context of Notifications: http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0029.html This makes sense when applicable, but I think the number of uses cases where permissions can be inferred from user actions is rather small. Although I agree that too many prompts (and prompts in general) are annoying, the proposals in the referred minutes [1] actually address that annoyance by allowing apps to skip them, if they are playing along some rules. For both developers and users this gives enough incentive to be taken seriously. I like the idea presented in Mounir's doc about separating permission semantics from the API/mechanism of handling them. Granularity of needed permissions has always been a hard compromise to set, and would be difficult to standardize. For instance, take your example where you talk about separating permission grants (something I always hoped for). When the user can deny some of the permissions, it may cause dependency issues, which the apps could resolve either silently (in good case), or through a user dialog - but for the latter it would -again- need an API. Also, an API could help user decision, e.g. by the ability to give a short description on how exactly the feature is used (e.g. how/when the camera is used), and taking it further, if that could be expressed in a both presentable and formalized way, then it could be even enforced by the system. That is where the needed granularity plays an important role. Standardizing that would be hard, and it's not independent from the set of policies which need to be supported. Speaking about policies, choosing one (e.g. the remember for a day or similar) policy is not universal, and there may be smarter ones in a platform, e.g. an algorithm which chooses about prompting policy as referred in the mentioned minutes [1]. Probably we don't need to support an infinity of them either, but a certain set of web policies could be supported. Mounir's doc addresses some of the things needed for this, and fuels the slightly ambitious hope of standardizing a mechanism making possible to implement multiple policies (or no policies). Let's see, but I wouldn't like to see it cut off this early :). [1] https://docs.google.com/a/intel.com/document/d/1sPNHXRy7tkj0F2gdTtRHj9oFRNhQkaQy2A9t-JnSvsU/preview Best regards, Zoltan
Re: Proposal for a Permissions API
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 managing permissions differ. Sometimes permissions aren't queryable. It's my stated opinion that ignoring these issue will not make them go away. And delaying addressing UX and consistency issues just contributes to a proliferation of bad UX and inconsistent and difficult to use APIs. On Thu, Sep 4, 2014 at 9:05 PM, Kis, Zoltan zoltan@intel.com wrote: 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 explicit permissioning is an attractive nuisance which future spec authors will be drawn to. We should be avoiding adding features to the platform that have to resort to explicit permissioning. Instead of adding features which require prompting for permission, we should be designing features—like drag drop or input type=file—that don't require prompting for permission at all. I don't think much has changed since this last came up, in the context of Notifications: http://lists.w3.org/Archives/Public/public-web-notification/2012Mar/0029.html This makes sense when applicable, but I think the number of uses cases where permissions can be inferred from user actions is rather small. Although I agree that too many prompts (and prompts in general) are annoying, the proposals in the referred minutes [1] actually address that annoyance by allowing apps to skip them, if they are playing along some rules. For both developers and users this gives enough incentive to be taken seriously. I like the idea presented in Mounir's doc about separating permission semantics from the API/mechanism of handling them. Granularity of needed permissions has always been a hard compromise to set, and would be difficult to standardize. For instance, take your example where you talk about separating permission grants (something I always hoped for). When the user can deny some of the permissions, it may cause dependency issues, which the apps could resolve either silently (in good case), or through a user dialog - but for the latter it would -again- need an API. Also, an API could help user decision, e.g. by the ability to give a short description on how exactly the feature is used (e.g. how/when the camera is used), and taking it further, if that could be expressed in a both presentable and formalized way, then it could be even enforced by the system. That is where the needed granularity plays an important role. Standardizing that would be hard, and it's not independent from the set of policies which need to be supported. Speaking about policies, choosing one (e.g. the remember for a day or similar) policy is not universal, and there may be smarter ones in a platform, e.g. an algorithm which chooses about prompting policy as referred in the mentioned minutes [1]. Probably we don't need to support an infinity of them either, but a certain set of web policies could be supported. Mounir's doc addresses some of the things needed for this, and fuels the slightly ambitious hope of standardizing a mechanism making possible to implement multiple policies (or no policies). Let's see, but I wouldn't like to see it cut off this early :). [1] https://docs.google.com/a/intel.com/document/d/1sPNHXRy7tkj0F2gdTtRHj9oFRNhQkaQy2A9t-JnSvsU/preview Best regards, Zoltan
Re: Proposal for a Permissions API
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 show all of the above all at the same time? - 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 managing permissions differ. Sometimes permissions aren't query able. It is more worthwhile addressing the above, so to avoid the sequence of pop-ups. It's my stated opinion that ignoring these issue will not make them go away. And delaying addressing UX and consistency issues just contributes to a proliferation of bad UX and inconsistent and difficult to use APIs. Absolutely, we should be addressing them at the API level. For instance, adding a way to determine if the permission has been granted in Geo without actually needing to use the API.
Re: Proposal for a Permissions API
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 so that you can geotag the videos - Get access to the notifications API so that you can inform the user when rendering has finished. - Get user media to capture material - Put a window in fullscreen (perhaps on a second monitor) or to view footage without other decorations Of course it's a bit contrived, but it's an example of where we're steering to. APIs don't stop being introduced as of today, and some years down the road, I'm sure more APIs that require permissions will be introduced, which increases the likelihood of moving such an example from the realm of unlikely to pretty common.
Re: Proposal for a Permissions API
-- 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? Let's say you're writing a video editor, you'd like: - To get access to the locations API so that you can geotag the videos - Get access to the notifications API so that you can inform the user when rendering has finished. - Get user media to capture material - Put a window in fullscreen (perhaps on a second monitor) or to view footage without other decorations A developer can then have a Let's get started! screen, where they explain why they need each feature before they request it. Of course it's a bit contrived, but it's an example of where we're steering to. APIs don't stop being introduced as of today, and some years down the road, I'm sure more APIs that require permissions will be introduced, which increases the likelihood of moving such an example from the realm of unlikely to pretty common. Absolutely. I the above, a dev could still ask for each API as needed. Like: Ok, let's get your camera working. We need you to grant us access to it. Get user media Great! will you want to geotag your videos? If so, confirm the prompt. You can always turn this off in the app later. geolocation (or a checkbox-like option in their app - this can be enabled during recording even!) fullscreen is just a button in the UI: works just like it does today. None of the above e require all permissions to be asked at once. There is a great article that discusses this approach: http://techcrunch.com/2014/04/04/the-right-way-to-ask-users-for-ios-permissions/
Re: Proposal for a Permissions API
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 writing a video editor, you'd like: To get access to the locations API so that you can geotag the videos Get access to the notifications API so that you can inform the user when rendering has finished. Get user media to capture material Put a window in fullscreen (perhaps on a second monitor) or to view footage without other decorations Of course it's a bit contrived, but it's an example of where we're steering to. APIs don't stop being introduced as of today, and some years down the road, I'm sure more APIs that require permissions will be introduced, which increases the likelihood of moving such an example from the realm of unlikely to pretty common. This could make a good case study. A site that continually prompts the user could negatively affect the user experience. If the designers of the site appreciate the fact, then they might ask for fewer permissions. They might even segregate functionality into different areas of the site with different permission requirements to lessen the burden on a user. Its kind of like a forced attrition into principal of least privilege. If there are no hurdles or obstacles, then sites will ask for everything whether they need it or not. The web will degenerate into an Android flashlight app. Given browsers are going to be executing high value code and handling high value data (cf., secure origins) and the two choices above, I think I would rather have the prompts.
Re: XMLHttpRequest. Support for OPTIONS * method.
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 something they anticipate a browser to do. -- http://annevankesteren.nl/
Re: XMLHttpRequest. Support for OPTIONS * method.
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 using XMLHttpRequest class? That is not supported. I suspect adding support for it might create a security vulnerability for servers as it is not something they anticipate a browser to do. -- http://annevankesteren.nl/ -- Mark Nottingham http://www.mnot.net/
Re: Proposal for a Permissions API
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 and firefox) and stuff won't work and the site makes a sad face. Putting it up front is one way to avoid a bad user experience. It's likely APIs that require permissions will proliferate, which makes it more likely to run into the bad cases. There are other motivations to put permissions up-front though. For instance if you enter pointerlock, then in order to click on the permissions, the browser needs to throw the user out of pointerlock, but you're not getting back into pointerlock by itself, so you need to reaquire it, which necessitates a user interaction. Sometimes a set of functionality (like say geolocation and user media) is often requested together, so it makes it again more likely to run into the bad cases. Pointerlock fullscreen solved this issue by coalescing the permission for both into a single dialog if both are requested. Merging pointer lock and fullscreen requests has worked well in Chrome, particularly allowing that merging to happen independently of request order or timing allowing for them to be joined after a delay. Additional UI presentations of this merging have been considered over time and the browser has great flexibility in how to guide the user through an informed choice. Continuing to support the browser merging requests is valuable. Merging doesn't require an API specifically built to bundle, also as demonstrated by pointer lock and fullscreen which Chrome merges without a unified or explicit API. However, code legibility, maintainability, and developer intent would all benefit. Ability to merge also doesn't imply that a webpage can not offer interstitial explanation of requests to increase user engagement. I'd also argue that users who click through unwarranted large permissions groups in order to access simple apps such as flashlights are just as likely to click multiple times to sequential requests.
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 was really only being 1 version behind at the time). In ES6, there is [finally] a syntax introduced for importing and exporting modules (libraries, etc.). For some quick examples, you can peek at the ECMAScript wiki http://wiki.ecmascript.org/doku.php?id=harmony:modules_examples. A transpiler is a tool that can take code written in one version of the language syntax and convert it to another [older] version of that language. In the case of ES6, you'd want to look into using es6-module-transpiler http://esnext.github.io/es6-module-transpiler/ to convert ES6-style imports/exports into an AMD (asynchronous module definition) https://github.com/amdjs/amdjs-api/blob/master/AMD.md format. That is, of course, assuming that your Java2Script translation could be updated to output ES6 module syntax. Sincerely, James Greene On Thu, Sep 4, 2014 at 4:55 PM, Robert Hanson hans...@stolaf.edu wrote: 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 can see, what I would need if I did NOT implement async throughout Jmol is a suspendable JavaScript thread, as in Java. Is that on the horizon? Bob Hanson
