w3c-webmob / installable-webapps Goto Github PK

Relevant bugs @ mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=798223
https://bugzilla.mozilla.org/show_bug.cgi?id=854956
https://bugzilla.mozilla.org/show_bug.cgi?id=907471

http://indiewebcamp.com/icon

I think the best option would probably be to add an appendix about the october data set describing the situation and the caveats from the dataset (e.g: not using a mobile UA, so some websites might have done UA sniffing and served a desktop website without mobile specific meta tags)

Then we link to that appendix rather than using the current link to the gist we have right now.

http://stackoverflow.com/questions/3024745/cross-browser-bookmark-add-to-favorites-javascript

See:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23204
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Sep/0095.html

See:
http://junkyard.damowmow.com/529

• Websites nagging users to install the native app (cover iOS App Banners)
• Webapps not working unless installed
• Native apps in Android asking for more permissions than they require
• JS hack in iOS standalone apps to work around navigation limitations (point 8.3)

Need to describe the problem at the moment that even if you get the localized name, the application won't be localized. The navigator.language is the navigator language, so the application has no way of knowing (currently) that the system language has changed. This would require a change to how the web platform interfaces with the OS to get the user's language. This has privacy issues, as it helps narrow down a user's geographic location down to a country. The HTML5 spec currently tries to protect users from this by telling the UA to always report "en-US".

In section http://w3c-webmob.github.io/installable-webapps/#ios---touch-icons we have:
"On iOS, when web pages doesn't specify a custom touch icon [...]".
It should read "web page".

Issue moved from w3c/manifest#342

Elsewhere, Rob Manson wrote:

..the common experience especially on iOS is that even when you background
an installed app and then foreground it again it reloads the entire
state. This effectively breaks the UX and makes this mode almost
unusable. It's definitely possible to use localStorage, etc. to work
around this but the UX is horrible. Allowing installed apps to persist
their resources and loaded state across background/foreground (and
ideally even launches) would be a massive step forward. Perhaps naming
this a "First use page" would help clarify this focus?

Need to document the use case for a "display name" and a "store name" and what roles they play. Particularly, in iOS, you can search using both the store name and the display name.

Some apps use different orientations depending on if they are running a phone vs on a tablets vs on desktop. Need to check how often this happens.

this site contains some very useful info about "install this app" frustration:

http://idontwantyourfuckingapp.tumblr.com/

Elsewhere, Mark Taylor wrote:

Specification assumes that the entire app is self contained and requires a consistent
display mode

Most web apps will have both internal links (to other parts of the web app), and external
links to elements outside of the web app. External links often do not contain a route back
to the web app, so the preferred behaviour is either for it to a) launch in the web browser,
or b) launch within the app, with a navigation element allowing users to return to the
web app.

Need to change the following:

"MUST provide a mechanism that allows a developer to indicate that the
application is able to function as standalone. If no such indication is
given by the developer, then the application MUST launch in the Web
browser as normal. That is, the solution MUST NOT conflate bookmarking
with allowing a web application to be launched as standalone. "

... to make it clear that it's actually a user's decision, but the manifest format needs to give the developer control over some start-up options for standalone.

See:
https://code.google.com/p/chromium/issues/detail?id=323307

Need to see if @PaulKinlan et al. needs anything else.

I guess some website / webapp have different name/title depending on the locale. I believe Firefox OS allows that. It would be great to have this issue raised in the document.

Elsewhere, @mattbasta wrote:

The sandbox attribute allows you to block same-origin access, prevent top-level navigation, block scripts, and blocking form submission.

This would be great for sites that wrap other sites as apps (consider everything.me) and could provide a way for users to standalone-ize their favorite sites without worrying about the site breaking out of the standalone environment.

Reference "Installable Web Apps", http://w3c-webmob.github.io/installable-webapps/.

From the Introduction:

"...the web platform also lacks sufficient metadata for a Web application to be successfully integrated into an operating system in the same way native applications are (i.e., not just on the homescreen, but integration into other contexts such as the task switcher, privacy and security settings, etc.)."

I think "operating system" could be changed to "platform". The platform includes hardware, os, features and capabilities, etc. The os is usually discussed in a more narrow context, and the description does not appear to be speaking to the narrow context.

We can probably draw on the following to strengthen the findings. It's not as accurate, but it's covers a much much larger data set so it could be used to strengthen findings.

http://git.macropus.org/meta-tag-usage/

At Mozilla's bugzilla a discussion woke up ( https://bugzilla.mozilla.org/show_bug.cgi?id=424875 ) to make XMLHttpRequest useable for web-applications on the file-protocol without requiring the server to enable CORS. At the end of the current discussion I got the idea of a system-wide configuration file to solve this issue:

• It contains permissions it grants to web-applications (for example specific/all permissions on specific files/directories).
• Installer invoked by the user can write the required permissions for their web-application to this file. Also the user can enter manually entries if he wants.
• A site launched unintentionally on the file-protocol can't do evil things since it wouldn't be listed in this file.

This would help to make web-applications launched on the file-protocol (for example installed by upstream-installers on desktop-PC's) to be more competitive.

Elsewhere, Rob Manson wrote:

Much of this work (and HTML5 in general) is about bringing the Web Platform up to being "equal" with "native apps". But one thing that the Web does that native apps can't do is deep linking (ignoring the fustercluck of intents). I think it would provide a significant advantage if it was also possible to deep link into installed web apps. I understand this is very complex and I'm not proposing any solution right now. But if we don't include this then we are in effect cutting web applications down to the level of native apps instead of leaping ahead of them.

Use Case: Social sharing

User A and User B both have the same web app installed on the devices they are using. User A finds a resource they like inside the app and decide to share this from within the app through one of their social networks. User B sees this link in their social feed and taps on it. Since User B also has this web app installed it would be "nice" to be able to open that resource directly within the installed app. Otherwise User X's browser would just open it like a normal web resource. This can also be relevant for the same user using the same web app across multiple devices.
NOTE: This is one of the key drivers we have found for building business cases of "Web instead of Native".

Elsewhere, @AMorgaut wrote:

Regarding permissions for Device APIs being listed in the manifest, I thought a previous proposal

• http://www.simonheckmann.de/proposal/

and the related discussion on the WHATWG mailing list to which I participated :

• http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Apr/0268.html
• http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Apr/0274.html

may worth a read

Based on the comments about the standalone mode in the manifest app, it would be good to expand more into the use cases for standalone, chrome and fullscreen.

See w3c/manifest#76

The document should investigate the use of splash screens on native platforms, to help inform: w3c/manifest#9

Elsewhere, @AMorgaut wrote:

Regarding permissions for Device APIs being listed in the manifest, I thought a previous proposal

• http://www.simonheckmann.de/proposal/

and the related discussion on the WHATWG mailing list to which I participated :

• http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Apr/0268.html
• http://lists.w3.org/Archives/Public/public-whatwg-archive/2011Apr/0274.html

may worth a read

Described here.

FxOS made the mistake of assuming one application per origin - need to check what happened and anything we can recommend as a requirement.

See:
https://bugzilla.mozilla.org/show_bug.cgi?id=778277

The msPinnedSiteState seems to serve the same purpose as Apple's window.navigator.standalone.

http://msdn.microsoft.com/en-us/library/ie/dn255016(v=vs.85).aspx

The document should investigate some of the manifest solutions:

• [Microsoft's browserconfig.xml] - http://msdn.microsoft.com/en-us/library/ie/dn320426(v=vs.85).aspx
• Mozilla's application manifest
• Google's hosted apps manifest

Hi,

On the iPhone there's also link rel="apple-touch-icon" href="/custom_icon.png"

@Hixie sez:

08:08 Hixie: i disagree with "the web platform lacks a standardized means for a web application to indicate that it can be "installed" and treated as if it were an native application"
08:08 Hixie: the standardised means of indicating that a page can be installed is for the page to exist

He is right. Need to change this to say that "orientation" and a few other bits and bobs are missing from the platform.

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.

It would be good to look at how localization is handled in web applications. Then we can see how this relates to the manifest.