Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

URL schemes supported in presentation API #76

Closed
louaybassbouss opened this issue Apr 10, 2015 · 7 comments
Closed

URL schemes supported in presentation API #76

louaybassbouss opened this issue Apr 10, 2015 · 7 comments
Assignees
@louaybassbouss
Labels
F2F resolution v2

Comments

@louaybassbouss
Copy link
Contributor

Presentation API addresses currently presentation of hosted web content (e.g. accessible via http:// or https://). According to the spec, presentation URLs follows the URL Standard. Questions is: are there other relevant URL schemes for Presentation API? for example data: scheme can be used in the following way:

var presentationUrl = 'data:text/html,<!DOCTYPE html><html><body><p>Test</p><script>/* inline JavaScript that may use navigator.presentatoion.session */</script></body></html>';
var session = navigator.presentatoion.startSession(presentationUrl);

Also the file:// protocol could be relevant for non-hosted web content for example for Packaged Web Application like W3C Widgets.

All relevant schemes need to be evaluated regarding limitations, security implications, performance etc. for usage in Presentation API. Also use cases to derive requirements are needed.
@louaybassbouss
Copy link
Contributor Author

@anssiko comment on this:

That is a good question. Whatever we decide, we should specify the expected behaviour in order to allow the implementations to interoperate after we've figured out whether the API should work with data URIs.

I think there may be a disagreement among implementers whether data URIs are same-origin depending on where they're used (Worker, iframe, img, open()...). I think the closest existing API to startSession() where data URIs can be used is open().

I think the primary motivation for using data URIs has been performance. HTTP/1.x has known limitations in loading multiple resources concurrently, so inlining all the resources has improved the performance. Another use case I can think of is to be able to provide a single file that contains all the resources without the need to package multiple files together.

Louay, All - I think you should investigate this further and come up with a recommendation on how to proceed i.e. whether data URIs should be allowed or not, and how to spec that

@louaybassbouss louaybassbouss self-assigned this Apr 10, 2015
@markafoltz
Copy link
Contributor

Another open question is whether vendor- or OS-specific schemes are allowed. For example, a Chrome extension or app may want to present content which would be hosted by that extension/app (using the scheme chrome-extension://). Or a browser on a mobile device may want to present content that is available to a native application on the device (via some OS-specific scheme).

These scenarios may just be user agent specific features that are a superset of the specification, and not part of the specification itself.

@tidoust tidoust mentioned this issue May 11, 2015
Closed
@anssiko
Copy link
Member

anssiko commented May 20, 2015

PROPOSED RESOLUTION: do not restrict extensions that might want to make use of other URL schemes than http(s), however those alternative schemes are out of scope for v1

Relevant discussion at Berlin F2F: http://www.w3.org/2015/05/20-webscreens-minutes.html#item08

@markafoltz markafoltz mentioned this issue May 27, 2015
Merged
@markafoltz
Copy link
Contributor

@louaybassbouss, I just posted a pull request with some proposed text for this issue. Please review when you have a chance.

@louaybassbouss
Copy link
Contributor Author

thx @mfoltzgoogle I just replied to PR #96. I think we can close this issue for now.

@anssiko
Copy link
Member

anssiko commented Jun 1, 2015

Since this issue contains a PROPOSED RESOLUTION from the F2F, we should keep this issue open until 10 working days have passed from the F2F meeting. That is, if by 3 June 3 2015 no concerns have been raised, we can convert this and other PROPOSED RESOLUTIONs into RESOLUTIONs, after which we can close such issues if they have been addressed.

However, we can (and are encouraged to) land changes to the Editor's Draft spec meanwhile without the need to wait for 10 days in order to do so (a la commit-then-review). By keeping the issues with PROPOSED RESOLUTIONs open for 10 days after the F2F we make it obvious to people not at F2F that the resolutions are indeed proposed until 10 days have passed, and any concerns can be raised.

@markafoltz
Copy link
Contributor

Now that the consensus window has passed, and we have implemented the proposed resolution with PR #96, closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@louaybassbouss louaybassbouss

Labels
F2F resolution v2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@anssiko @louaybassbouss @markafoltz