Proposal: <title title="Long, detailed, SEO-friendly etc. title">Short app name</title>

[mathiasbynens]

http://w3c-webmob.github.io/installable-webapps/#names

Instead of a separate <meta> element, why not just use a title attribute on the <title> element?

<title title="Long, detailed, SEO-friendly etc. title">Short app name (for homescreens)</title>

Joel_MMCC makes the case for this pattern here: http://mathiasbynens.be/notes/touch-icons#comment-76 IMHO it’s hard to disagree with the points he’s making. I’ll echo his comment here:

On the matter of shorter vs. longer web page titles, it looks like the HTML spec itself allows for this already, without needing anything new added to the spec, and requiring absolutely no proprietary vendor metatags (e.g. Mathias’s <meta name="apple-mobile-web-app-title" content="Short title for home screen"> above).

It’s so simple! According to the HTML 5 spec (and I believe HTML 4 as well), the title="…" attribute is a global attribute that can be used with any HTML tag! That includes the <title> tag itself!

So, hypothetically, you could do this:

<title title="Long SEO-friendly overly verbose page title goes here">Short title here.</title>

Voila! This should even validate nicely, as-is!

Now all that’s needed is for user agents (browsers and spiders) to decide what to do with that. I recommend a “smart” approach: For touch icon titles and the like, always use the shorter title that is the inner content of the <title> tag.

For browser window titles, likewise display the inner content of the <title> tag if the browser window is too narrow to display the longer one in the title="…" attribute (e.g. portrait orientation, manually reduced in size, etc.).

Search engines can simply use both as they see fit for their metadata and rankings.

There’d also be no reason that the two couldn’t be swapped (longer title as the tag’s inner content, shorter as the title="…" attribute, instead of vice versa) and have the user agent simply react intelligently based on which is longer and which is shorter, but traditionally the title="…" attribute is used to provide longer descriptive text for some usually shorter or smaller element via a ToolTip (e.g. for <img>, <a>, <abbr>, <acronym>, etc. tags), so that should be the preferred usage.

[marcoscaceres]

@mathiasbynens the document we are working on will present the use cases and requirements, as well as summary of what each browser does - but we are not making recommendations for solutions at this point. So, it would be a requirement that a standard provide a means for an application to have both a short name and a long name.

Your write up on icons would be sooooo perfect to drop into our document. Is there any chance you could contribute that section? pretty pretty pretty please with 🍒 on top?????? It would be super helpful in informing the standardization process.

[mathiasbynens]

@marcoscaceres Sure! I hereby give you permission to use all of http://mathiasbynens.be/notes/touch-icons for this document. Is there anything else I can do to help with this?

[ernesto-jimenez]

@mathiasbynens @marcoscaceres FYI, Apple also uses a different set of icons for Push Notifications in Safari.

You can find the information in the apple developer docs:

BayAirlines.pushpackage/
    icon.iconset/
        icon_16x16.png
        icon_16x16@2x.png
        icon_32x32.png
        icon_32x32@2x.png
        icon_128x128.png
        icon_128x128@2x.png
    manifest.json
    signature
    website.json

It's not directly related to installable web apps, but I thought it might be interesting to point that out in case this might be interesting when defining the specs. I could se the webapp manifest include information for push notifications instead of having a different manifest like apple does.

[marcoscaceres]

Closing this, as using title attribute on the <title> element as a short name should really be raised with the WHATWG. The doc we are working on will only recommend use cases and requirements - though we will document the use of short names of applications on various platforms. See #25