Add meta tags equivs. for features were possible #350

kornelski · 2015-04-06T08:25:00Z

I've implemented manifest on app.ft.com (it's not live yet), and my feedback is:

The basic properties we needed (name and start URL) are redundant with numerous <meta> and <link> elements we have already (including proprietary ones such as apple-mobile-web-app-title and msapplication-starturl).
JSON is unpleasant to work with. It's unsuitable for manual authoring due to lack of comments and draconian XML-like error handling, but having to use a serializer for just a couple of properties feels silly, especially that we've had code to serialize metadata already — in HTML.
external file feels unnecessary given how tiny it is.
Adding a few more <meta> elements is not a problem at all for us, because when they're surrounded by very similar markup they gzip to almost zero. We already emit <meta> and <link> elements for "legacy" specs, social media sites, and vendor-specific features.

So overall I'd strongly prefer an option to use <meta> and <link> equivalents for basic Manifest features, to reduce overhead (both on-the-wire overhead due to inlined gzipped data, and maintenance overhead thanks to reusing existing HTML-meta pipeline instead of creating a new JSON one). As a bonus, they'd be localizable #338.

The text was updated successfully, but these errors were encountered:

marcoscaceres · 2015-04-06T17:13:57Z

@pornel this is great feedback; thanks! We could look at standardizing the additional meta tags to provide all the fall backs (so you don't need JSON at all).

marcoscaceres · 2015-04-06T17:18:54Z

Related to: #97

marcoscaceres · 2015-04-06T19:12:12Z

@pornel Can you ping me when you put up the manifest? Also, hypothetically speaking: do you foresee using a CDN for hosting the manifest?

kornelski · 2015-04-06T19:57:32Z

I'll ping you, but it'll be disappointing, since it's currently minimal :)

I haven't thought about any special hosting for it, but we're moving the entire app behind a CDN, so technically it'll be on a CDN too.

marcoscaceres · 2015-04-06T20:09:50Z

I'll ping you, but it'll be disappointing, since it's currently minimal :)

Minimal is good. Makes a case for dropping redundant stuff.

I haven't thought about any special hosting for it, but we're moving the entire app behind a CDN, so technically it'll be on a CDN too.

This is going to sound like a really stupid question (but important for an ongoing debate in #272), but how much of an issue would it be for FT if the browser didn't allow you to host this on a CDN (i.e., the manifest was forced to be same origin)? If that is a problem, what would you do instead?

marcoscaceres · 2015-04-06T21:58:08Z

We currently define:

short_name === meta@name=application-title
name === <title>
icons === link@rel=icons
theme_color === meta@name=theme-color

Currently missing HTML meta equivs. for:

display
orientation
start_url
lang - could grab HTMLHTMLElement.lang?
scope - scope is very manifest specific.

Thoughts on the above?

marcoscaceres · 2015-04-06T22:11:48Z

Actually, for lang we can walk the tree to find the language of the document.

So, we can get it from the element:

<link rel=manifest lang=en>

Or parent(s):

<html> 
  <head lang=fr>
  <link rel=manifest>

Or root:

<html lang=fr> 
  <head>
  <link rel=manifest>

marcoscaceres · 2015-04-06T22:19:32Z

And HTML to the rescue :) https://html.spec.whatwg.org/multipage/dom.html#language

kornelski · 2015-04-06T23:00:47Z

For lang it may be worth testing on some web crawl — is <html lang> popular enough? Do people use <body lang>? I'd limit to reading lang attr just from the root for simplicity.

Looking at https://wiki.whatwg.org/wiki/MetaExtensions and https://msdn.microsoft.com/en-us/library/ie/gg491732%28v=vs.85%29.aspx

name ➡️ application-name (existing specs and examples don't focus on limiting length of the name).
short_name ❓ Something needs to be defined (in iOS the de-facto short name is apple-mobile-web-app-title, but naming scheme doesn't fit the rest).
start_url ➡️ In the olden days it was <link rel=start>, but there's probably too much legacy content with this. ~~Google tried <meta name=application-url>~~. MS has msapplication-starturl. Perhaps <link rel=application-start>? (it should be a link).

Agreed re icons, theme-color. I think you're on the right track.

marcoscaceres · 2015-04-06T23:18:29Z

I think we really want short_name to be application_name, because short_name is what is used under icons when you add the app to the homescreen... on the other hand, name is used as an alternative name when searching for an app (e.g., on my iphone: name = "Google Translate"; short_name = "Translate" ... same with names like, say "google chrome" ... I search for "Google", I see "chrome" come up in the list of installed apps).

kornelski · 2015-04-07T11:48:32Z

No question that both are useful and needed. HTML has only one name defined so far, so a second one will have to be defined one way or another.

I'm suggesting mapping manifest name to meta application-name, because the HTML spec didn't say anything about icon labels or length limitations of that meta. Also, if we define application-short-name then mapping of both will be obvious.

name -> application-name
short_name -> application-short-name

In practice I expect it to be implemented by UAs as a chain of fallbacks: use application-short-name if present, fall back to application-name, then fall back to truncating <title>.

benfrancis · 2015-04-07T12:02:04Z

We currently define:
name === <title>
icons === link@rel=icons
theme_color === meta@name=theme-color
...
Thoughts on the above?

I disagree with this. These HTML tags define the title, icon and theme_color of a web page, not of a web application. A web application consists of multiple web pages, which is the reason for the scope property.

If all the manifest is doing is providing an alternative way to define metadata for a web page, there's very little point in its existence. See #272.

kornelski · 2015-04-07T13:02:16Z

@benfrancis What's the use-case for having this distinction? How does it affect consumers of the metatags?

To me it seems the distinction is only theoretical, especially for single-page apps.

benfrancis · 2015-04-07T13:13:01Z

@pornel For a web app with only one web page, the distinction is largely redundant. But most web apps consist of multiple web pages.

The metadata of the manifest is intended to be applied to a browsing context to create an application context, the metadata then applies to all web pages loaded inside the application context. i.e. The manifest describes a web application as a whole, whereas the meta tags of a document just describe one page of a web application or web site.

In the context of the FT app, I would say that the name of the app might be "FT", whereas the title of an individual page might be "UK banks urged to boost profitability", the title of a particular article.

A user agent might use the name of the app for a launcher, but display the title of a particular page in a task switcher for example. Both are useful.

benfrancis · 2015-04-07T13:19:50Z

(I imagine search engines would also want to distinguish between a particular news article and the news app as a whole when displaying search results).

kornelski · 2015-04-07T13:46:59Z

Yes, I agree about <title> (that's why HTML has application-title).

I was assuming theme-color is used as application-wide (that's how FT app and BBC news use it), but I can imagine apps having dynamically changing theme (in FT we have Weekend section where we could theoretically change the theme meta).

In that case how about having mapping of manifest fields to meta with application- prefix, such as application-theme-color, application-icon?

marcoscaceres · 2015-04-07T15:16:58Z

In that case how about having mapping of manifest fields to meta with application- prefix, such as application-theme-color, application-icon?

Something like that could work.

PaulKinlan · 2015-04-08T12:22:56Z

I do agree having a sane fallback from manifest to meta elements makes sense and it is something we use on Chrome. Some of my issue with this is that the meta tags describe things related to the page and the manifest describes things relate to an installable experience and it is a subtle difference.

re: Google tried "application-url" - no we never :) well, it is actually really really unclear about what was happening at that time. For all intents and purpose we never did if anyone cares about usage on the web.

One thing that the Microsoft sorted with their original meta tags was "what to launch" which is one of the biggest pieces that was missing from most usages of meta tags that I would like to see defined.

benfrancis · 2015-04-10T19:01:30Z

Some of my issue with this is that the meta tags describe things related to the page and the manifest describes things relate to an installable experience and it is a subtle difference.

I think this is the key point. If a web site is a collection of web pages then a web app is an installable web site, not an installable web page.

Until now we've not really had a way to provide metadata about a web site as a whole, only about individual pages, the manifest provides this. I'm not sure a web page is the right place to store metadata about a web site. This would require adding metadata like below to every page of a web site:

<meta name="application-lang" content="en">
<meta name="application-name" content="My App">
<meta name="application-short-name" content="My">
<meta name="application-scope" content="/">
<meta name="application-icon" content="/icon.png">
<meta name="application-display" content="standalone">
<meta name="application-orientation" content="portrait">
<meta name="appllication-start-url" content"="/index.html">
<meta name="application-theme-color" content="blue">

You could do it like that, in the same way that you could inline your CSS on every page. It just seems more efficient to put it in a separate file and link to it with a link relation, like we do with other resources that are shared between multiple pages of a web site, like stylesheets.

kornelski · 2015-04-11T00:21:06Z

@benfrancis, sure, web pages and webapps are different (and sometimes it's fuzzy and complicated), but it doesn't matter here! It's a red herring.

The use cases work just fine without caring about this distinction. We know this for a fact, because such metatags are already successful and in widespread use, but with an apple- prefix.

I completely disagree with you about bandwidth being a problem. I think there are key things that must be considered:

This proposal doesn't take away ability to use external manifest file.
In every situation where metatags wouldn't be suitable one can use an external manifest file instead, so nobody is worse off.
Metatags are an overhead only if HTML is reloaded, but webapps (almost by definition) do that very rarely.
Extensive use of DHTML, AJAX and/or some form of offline storage is pretty much expected from webapps that are going to be installed among native apps.
Your example gzips to 175 bytes. When it's compressed with other markup, it only adds 78 bytes to the page. Even in the very constrained case of optimizing for rendering in the initial 14KB TCP window, with HTTPS overhead, that's still 1% cost.
External CSS and JS matter only because they're literally thousands times larger than this. It seems wrong to always require use of optimizations designed for large files on manifest data that can be so tiny.

kornelski · 2015-04-11T00:38:12Z

@PaulKinlan Agreed! Without start URL we have to resort to ugly and fragile hacks with cookies and appcache to work around that. Ew.

marcoscaceres · 2015-05-05T21:31:27Z

Made the metadata in the manifest authoritative instead.

marcoscaceres changed the title ~~Allow using metatags instead of JSON~~ Add meta tags equivs. for features were possible Apr 6, 2015

marcoscaceres added Feature Request P3 labels Apr 6, 2015

marcoscaceres added a commit that referenced this issue Apr 6, 2015

Made using fallbacks normative (closes #350)

b714bc8

marcoscaceres added P1 and removed P3 labels Apr 6, 2015

marcoscaceres closed this as completed May 5, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add meta tags equivs. for features were possible #350

Add meta tags equivs. for features were possible #350

kornelski commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

kornelski commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

kornelski commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

kornelski commented Apr 7, 2015

benfrancis commented Apr 7, 2015

kornelski commented Apr 7, 2015

benfrancis commented Apr 7, 2015

benfrancis commented Apr 7, 2015

kornelski commented Apr 7, 2015

marcoscaceres commented Apr 7, 2015

PaulKinlan commented Apr 8, 2015

benfrancis commented Apr 10, 2015

kornelski commented Apr 11, 2015

kornelski commented Apr 11, 2015

marcoscaceres commented May 5, 2015

Add meta tags equivs. for features were possible #350

Add meta tags equivs. for features were possible #350

Comments

kornelski commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

kornelski commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

kornelski commented Apr 6, 2015

marcoscaceres commented Apr 6, 2015

kornelski commented Apr 7, 2015

benfrancis commented Apr 7, 2015

kornelski commented Apr 7, 2015

benfrancis commented Apr 7, 2015

benfrancis commented Apr 7, 2015

kornelski commented Apr 7, 2015

marcoscaceres commented Apr 7, 2015

PaulKinlan commented Apr 8, 2015

benfrancis commented Apr 10, 2015

kornelski commented Apr 11, 2015

kornelski commented Apr 11, 2015

marcoscaceres commented May 5, 2015