updated on 19th of December
Thanks everyone who participated in the discussion! It was tremendously userful
So, what we are going to do initially is only support:
<link rel="manifest" href="...some URL...">
By virtue of this being a URL, if people really want to inline the manifest they can use a data:
URL:
<link rel=manifest href="data:application/manifest+json,{ ... }">
Credit to @yoavweiss for proposing the above on the public-webapps mailing list.
If, after some time, we find a lot of people are inlining manifests in the wild, we can return and look at alternatives - like using <script>
or <meta>
.
We are trying to create a new manifest format for the Web. It will allow you to define metadata for a web application in one place.
Right now, we are trying to decide how to "inline" the manifest into HTML. Need your feedback.
<!doctype html>
<html>
<head>
...
<meta name="manifest" content='{
"name": "Example",
"url": "/start.html",
"mode": "standalone",
"icons": [{
"src": "icon/lowres",
"density": "1",
"width": "64",
"type": "image/webp"
}, {
"src": "icon/hd",
"density": "2",
"width": "64"
}]
}'>
...
<!doctype html>
<html>
<head>
...
<script type="application/manifest+json">
{
"name": "Example",
"url": "/start.html",
"mode": "standalone",
"icons": [{
"src": "icon/lowres",
"density": "1",
"width": "64",
"type": "image/webp"
}, {
"src": "icon/hd",
"density": "2",
"width": "64"
}]
}
</script>
<link rel="manifest" href="app.json">`
OR
<script src="app.json" type="application/manifest+json"></script>
Please share it in the comments!
Using a
meta
element and JSON in thecontent
attribute is a terrible idea. Here's why.It forces using single quotes to wrap the
content
attribute, special-casing this attribute in the process. So while you can easily wrap anonclick
attribute with double or single quotes, e.g.:that wouldn't work for our manifest. The following works:
But this would not (the content isn't valid JSON):
This would be very inconsistent with the rest of the platform.
What happens when you have apostrophes within your content? When inlined using the
meta
element it would have to be escaped, e.g.:But that wouldn't be necessary when linking manifests. So copy/pasting from manifests originally written to be linked might end up wrecking havoc when used inline. (This is a situation analogous to closing
script
tags within inlined JavaScript which is a source of countless bugs).Using
meta
elements for each property, e.g.:won't work well for nested or enumerated content (try describing the icons mentioned above, it's hard), and it won't translate easily to a linked format.
Of course, the best option would be to create a
manifest
element, but that's not possible for legacy reasons (afaik, parsers switch to body content as soon as they find a tag which isn't blessed as that of a child of thehead
element).In conclusion, the only reasonable option is to use a script tag for inline content. For linked manifest, using the
link
element is appealing, but is inconsistent with using the script tag when inline, so I'd probably suggest using script tags for both.