Skip to content

Instantly share code, notes, and snippets.

@marcoscaceres

marcoscaceres/manifest-options.md

Last active December 13, 2022 02:00
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save marcoscaceres/7783977 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save marcoscaceres/7783977 to your computer and use it in GitHub Desktop.
Download ZIP
In-lining manifests.
Raw
manifest-options.md

Conclusions

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>.

Which one do you prefer?

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.

A - using a meta element and content attribute

<!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"
  }]
}'>
...

B - using a script tag

<!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>

External linking

<link rel="manifest" href="app.json">`

OR

  <script src="app.json" type="application/manifest+json"></script>

Got a better idea?

Please share it in the comments!

@tobie
Copy link

tobie commented Dec 5, 2013

Using a meta element and JSON in the content attribute is a terrible idea. Here's why.

  1. It forces using single quotes to wrap the content attribute, special-casing this attribute in the process. So while you can easily wrap an onclick attribute with double or single quotes, e.g.:

    <a href="#" onclick="alert('clicked!');">Click me!</a>
<a href='#' onclick='alert("clicked!");'>Click me!</a>

    that wouldn't work for our manifest. The following works:

    <meta name='manifest' content='{ "name": "Example" }'>

    But this would not (the content isn't valid JSON):

    <!--- THIS WON'T WORK -->
<meta name="manifest" content="{ 'name': 'Example' }">

    This would be very inconsistent with the rest of the platform.

  2. What happens when you have apostrophes within your content? When inlined using the meta element it would have to be escaped, e.g.:

    <meta name='manifest' content='{ "name": "Here\'s an example" }'>

    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.:

<meta name="app-title" content="Example">
<meta name="app-mode" content="standalone">

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 the head 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.

@dret
Copy link

dret commented Dec 5, 2013

regarding "We are trying to create a new manifest format for the Web" in the intro: isn't HTML5 defining just that in http://www.w3.org/TR/html5/browsers.html#offline ?
my guess this is more about the mechanics about how to to make it available? but isn't that also specified in HTML5 already? could somebody please briefly point out how this gist relates to what's specified in HTML5? thanks!

@dret
Copy link

dret commented Dec 5, 2013

if this is only about where to make the manifest available and how, then linking definitely should be the way to go. this way all the REST mechanics can apply: potentially multiple media types (if somebody ever comes up with a different manifest format), and maybe even PATCH formats for manifests if there are huge manifests, and there should be a way how diffs can be communicated. use web architecture as much as possible, and in this case, any solution other than linking seems vastly inferior. define and register a link relation type, and make sure that the linking mechanism does not hardcode the manifest media type to it.

@kevburnsjr
Copy link

kevburnsjr commented Dec 5, 2013

Require <link> and allow developers to reference inline manifests using fragment identifiers.

<link rel="manifest" href="#inline-manifest">
<script id="inline-manifest" 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>

@CodyErekson
Copy link

CodyErekson commented Dec 6, 2013

I like option B, using <script> tags. Mainly for portability reasons. Being able to easily pull this data into other code with little effort will probably be of enormous value.

Copy link

ghost commented Dec 7, 2013

external link to a JSON file, please no inline script tag, or JSON in meta tag.

@triblondon
Copy link

triblondon commented Dec 11, 2013

I agree with @tobie. We should have options for both external linking and inline embedding of the manifest data, and the only existing tag which gives us that ability in a <head> context is <script>. But, I would be concerned about shifting data for which there are already defined meta tags (as @pornel points out) into the manifest, as developers will then inevitably have to use both.

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