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

Add a web application manifest file #133

Closed
alrra opened this issue Feb 11, 2015 · 14 comments
Closed

Add a web application manifest file #133

alrra opened this issue Feb 11, 2015 · 14 comments

Comments

@alrra
Copy link
Member

alrra commented Feb 11, 2015

See:
@arthurvr
Copy link
Member

Added this to h5bp/html5boilerplate.com-mobile#9 too. PITA we have to do everything twice.

@arthurvr arthurvr mentioned this issue Feb 11, 2015
Closed
8 tasks
@alexgibson
Copy link
Member

Genuine query - but are manifest files not more to facilitate installation of web apps? (the common current use case being on mobile). Why add one to this site, what are the specific advantages here?

This seems like a perfect fit for Mobile Boilerplate, which is more web-app specific. But should every h5bp site (and also this website specifically) need this by default?

@alrra
Copy link
Member Author

alrra commented Feb 12, 2015

what are the specific advantages here?

@alexgibson Mainly for the "Add to homescreen" functionality (which is available in Chrome for Android, but also coming to Firefox). The basic idea is that if we add the apple-touch-icon we should also add this, more as an example then anything else.

@alexgibson
Copy link
Member

Firefox has already supported Open Web App manifest installation for some time, so it's great to see work standardising between two browsers here 👍

Apple touch icons are more akin to favicons on iOS (since any site can be bookmarked on the home screen by default). But I think simply bookmarking sites in this fashion is maybe an over simplification of what manifests serve to be.

Just my 2 cents :)

@alexgibson
Copy link
Member

Although I do see advantages in removing all that clutter in the <head> 😄

@alrra
Copy link
Member Author

alrra commented Feb 12, 2015

Apple touch icons are more akin to favicons on iOS (since any site can be bookmarked on the home screen by default). But I think simply bookmarking sites in this fashion is maybe an over simplification of what manifests serve to be.

@alexgibson I agree that it is oversimplification, but Chrome kinda when from using the apple-touch-icons to using (prior to v39) their own (?) syntax to using the web application manifest file. Firefox will do the same, and maybe then some of the other browsers will follow.

I think (and feel free to disagree) that, providing a starting web application manifest file is in general a good idea, even if it will not be used to its "full potential". Having a file that is requested only when needed, that basically contains the metadata for the site/web app, is a better way of doing things then cluttering the <head> of every page.

edit: Sorry, I missed your second comment.

@alexgibson
Copy link
Member

Some good points, I'm not strongly disagreeing with adding this, just curious as to the use cases for websites that don't require the more advanced features. Only thing I think the web needs to avoid apple-web-app-capable scenario where site publishers added it without really testing behavior thoroughly. 👍

@alrra
Copy link
Member Author

alrra commented Feb 12, 2015

Only thing I think the web needs to avoid apple-web-app-capable scenario where site publishers added it without really testing behavior thoroughly.

@alexgibson The only things H5BP can do to prevent that sort of issues is try to figure out a good default that is not harmful for anyone, and try to educate / point users to the right learning resources. Unfortunately, other then that, you can't really do anything to ensure that users will not do the wrong things.

@alrra
Copy link
Member Author

alrra commented Apr 30, 2015

This morning I wanted to close this issue, but it seems there is a bug in Chrome for Android (Blink) related to the CSP header:

e.g.:

  • If test.html contains <link rel="manifest" href="site.webmanifest">, and is served with the following CSP header:

    Content-Security-Policy: "default-src 'none';manifest-src 'self';report-uri http://192.168.2.105:8080/"

    Chrome won't request the manifest file when the user taps on the Add to Home screen menu item, as shown also by the CSP report:

    { 'csp-report': 
{ 'document-uri': 'http://192.168.2.105/',
 referrer: '',
 'violated-directive': 'default-src \'none\'',
 'effective-directive': 'manifest-src',
 'original-policy': 'default-src \'none\';manifest-src \'self\';report-uri http://192.168.2.105:8080/',
 'blocked-uri': 'http://192.168.2.105/site.webmanifest',
 'status-code': 200 } }

    The same happens if the CSP header is:

    Content-Security-Policy: "default-src 'none';manifest-src *;report-uri http://192.168.2.105:8080/"

    So, basically, the value specified by manifest-src directive doesn't overwrite the value specified by default-src.

Cc @marcoscaceres, @mikewest

Note: Didn't find an open issue on this (have to check again when I have more time), but if I haven't missed something from the specification (or something obvious), this looks like a bug.

@paulirish
Copy link
Member

@alrra sounds like a bug! can you file on crbug.com ?

@marcoscaceres
Copy link

@alrra, @paulirish, according to @kenchris, it's not enabled yet. @kenchris, can you provide details please.

@kenchris
Copy link

kenchris commented May 5, 2015

Yes, Chrome supports it, but as it wasn't in any spec at the point that I implemented it, it was put behind a flag. I guess an intent to ship needs to be send and we can enable it.

@roblarsen
Copy link
Member

we added one, I've just been punch drunk since the release.

@roblarsen
Copy link
Member

As above!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@paulirish @roblarsen @alexgibson @marcoscaceres @kenchris @alrra @arthurvr