Intent to implement and ship: (display-mode) media query feature of Web Application Manifest

139 views
Skip to first unread message

Kenneth Rohde Christiansen

unread,
Jan 15, 2015, 6:41:09 AM1/15/15
to blink-dev, mar...@marcosc.com
Primary eng emails

Spec

Summary
Add a media query feature for detecting the display mode used when launching/loading the web app. Default mode is 'browser' but other modes can be declared using a manifest: http://updates.html5rocks.com/2014/11/Support-for-installable-web-apps-with-webapp-manifest-in-chrome-38-for-Android

Motivation
Developers would like to be able to detect from JS and be able to use different styling depending on the display mode set in the manifest file.

This enables various use-cases such as 

* decide whether to promote "Add to homescreen";
* offer a different UI (like back button when in 'standalone');
* have data required to record usage metrics.

Similar JS API already exists on iOS navigator.standalone and web developers have requested the same for the new Web Application Manifest.



Compatibility Risk
Public support for the Web Application Manifest have been given by Chrome, Firefox and IE. Web developers have expressed interest in this addition and it has support from the developers working on Web Application Manifest at Google and Mozilla according to the GitHub issues.

Describe the degree of compatibility risk you believe this change poses
Low - It has been requested and discussed for a long time. iOS provides similar means. The 'display' field in the manifest is already shipping in Chrome so name is unlikely to change.

Ongoing technical constraints
None

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, and Android)? 
Yes, with the default value 'browser'. Platforms supporting the Web Application Manifest will support all supported display modes.

OWP launch tracking bug (Web Application Manifest):

Entry in Chromium Dashboard (Web Application Manifest):

Requesting approval to ship?
Yes - feature is relatively small.

PhistucK

unread,
Jan 15, 2015, 7:34:30 AM1/15/15
to Kenneth Rohde Christiansen, blink-dev, mar...@marcosc.com
In case anyone missed the start of this discussion, you can find it here -
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/LNRY0EzaAeY


☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Marcos Caceres

unread,
Jan 15, 2015, 8:58:02 AM1/15/15
to blink-dev, Kenneth Rohde Christiansen
On January 15, 2015 at 9:41:05 PM, Kenneth Rohde Christiansen (kenneth.ch...@gmail.com) wrote:
> > Compatibility Risk
> Public support for the Web Application Manifest have been given
> by Chrome, Firefox and IE. Web developers have expressed interest
> in this addition and it has support from the developers working
> on Web Application Manifest at Google and Mozilla according
> to the GitHub issues.

As one of the people implementing this on the Mozilla side, I'm excited to see this work happening in Chromium. We also have this feature on our todo list as part of our ongoing effort to implement the web manifest spec: 

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



Dimitri Glazkov

unread,
Jan 15, 2015, 5:19:48 PM1/15/15
to Marcos Caceres, blink-dev, Kenneth Rohde Christiansen
LGTM.

Philip Jägenstedt

unread,
Jan 16, 2015, 4:00:40 AM1/16/15
to Kenneth Rohde Christiansen, blink-dev, mar...@marcosc.com
LGTM, this sounds great.

In chrome/browser/android/shortcut_helper.cc it looks like standalone
is the only mode that does something, so I guess that (display-mode:
browser) and (display-mode: standalone) are the only media queries
which could currently match?

I'm curious if this ends up being mapped to Android's
setSystemUiVisibility flags in the end:
https://developer.android.com/reference/android/view/View.html#setSystemUiVisibility(int)

Android seems to have very many modes, are there enough modes in the
spec to map to all of the Android modes that make sense? Parity with
native and all that...

Philip

Kenneth Rohde Christiansen

unread,
Jan 16, 2015, 4:30:53 AM1/16/15
to Philip Jägenstedt, blink-dev, mar...@marcosc.com, Paul Kinlan
Hi Philip,

That is true, but the idea is supporting fullscreen etc in the future. Paul Kinlan was asking me or Mounir to have a look at adding support for fullscreen.

So to conclude, I will add support for (display-mode: browser) and (display-mode: standalone) for now, though the current patch also parses minimal-ui and fullscreen, but as those MQ will return false for now, so there is no user visible change (as invalid media queries also return false, ie "(display-mode: i-invented-this-weird-invalid-value)")

Regarding Android and various modes - Android is very flexible, but we need a set which solves the major use-cases for developers and which will work across different platforms like Firefox OS, etc. We are of course very interested in comments on whether we got the right set so far or whether we should expand it.

FULLSCREEN on Android currently hides the status bar but you can additionally use it in combination with other flags to "black out" the OS navigation buttons at the bottom. A lot of games are using fullscreen to hide the statusbar, but with the new IMMERSIVE mode (which hides status bar and OS navigation buttons) it is possible to use all of the real-estate and have it fade in when swiping down or up from the outside of the screen. This is currently what is used for the requestFullscreen mode which also exists when you swipe down/up.

If you have any data on what is most useful for developers for fullscreen - or whether we should add something like "immersive" mode, feel free to share with us or start a discussion in the spec issue tracker: https://github.com/w3c/manifest/issues

Cheers
Kenneth






On Fri Jan 16 2015 at 10:00:37 AM Philip Jägenstedt <phi...@opera.com> wrote:
LGTM, this sounds great.

In chrome/browser/android/shortcut_helper.cc it looks like standalone
is the only mode that does something, so I guess that (display-mode:
browser) and (display-mode: standalone) are the only media queries
which could currently match?

I'm curious if this ends up being mapped to Android's
setSystemUiVisibility flags in the end:
https://developer.android.com/reference/android/view/View.html#setSystemUiVisibility(int)

Android seems to have very many modes, are there enough modes in the
spec to map to all of the Android modes that make sense? Parity with
native and all that...

Philip

On Thu, Jan 15, 2015 at 12:41 PM, Kenneth Rohde Christiansen
<kenneth.christiansen@gmail.com> wrote:
> Primary eng emails
> kenneth.r.christiansen@intel.com
> email to blink-dev+unsubscribe@chromium.org.

Philip Jägenstedt

unread,
Jan 16, 2015, 5:51:12 AM1/16/15
to Kenneth Rohde Christiansen, blink-dev, mar...@marcosc.com, Paul Kinlan
Thanks Kenneth,

I'm afraid I don't have any data or particular wisdom to share on the
right set of modes. Since only browser and standalone are supported
now I guess you haven't yet had to decide how to map other modes
setSystemUiVisibility flags. I've filed an issue:
https://github.com/w3c/manifest/issues/304

Philip
>> <kenneth.ch...@gmail.com> wrote:
>> > Primary eng emails
>> > kenneth.r.c...@intel.com
>> >
>> > email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
Jan 16, 2015, 12:49:00 PM1/16/15
to Kenneth Rohde Christiansen, blink-dev, mar...@marcosc.com
On Thu Jan 15 2015 at 3:41:06 AM Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:
Primary eng emails

Spec

Summary
Add a media query feature for detecting the display mode used when launching/loading the web app. Default mode is 'browser' but other modes can be declared using a manifest: http://updates.html5rocks.com/2014/11/Support-for-installable-web-apps-with-webapp-manifest-in-chrome-38-for-Android

Motivation
Developers would like to be able to detect from JS and be able to use different styling depending on the display mode set in the manifest file.

This enables various use-cases such as 

* decide whether to promote "Add to homescreen";
* offer a different UI (like back button when in 'standalone');
* have data required to record usage metrics.

Similar JS API already exists on iOS navigator.standalone and web developers have requested the same for the new Web Application Manifest.



Compatibility Risk
Public support for the Web Application Manifest have been given by Chrome, Firefox and IE. Web developers have expressed interest in this addition and it has support from the developers working on Web Application Manifest at Google and Mozilla according to the GitHub issues.

Describe the degree of compatibility risk you believe this change poses
Low - It has been requested and discussed for a long time. iOS provides similar means. The 'display' field in the manifest is already shipping in Chrome so name is unlikely to change.

Ongoing technical constraints
None

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, and Android)?

There are six platforms: WebView was recently added. Do you intend to support it? If so, what would the semantics be?
 
Yes, with the default value 'browser'. Platforms supporting the Web Application Manifest will support all supported display modes.

OWP launch tracking bug (Web Application Manifest):

Entry in Chromium Dashboard (Web Application Manifest):

Requesting approval to ship?
Yes - feature is relatively small.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

owe...@google.com

unread,
Jan 16, 2015, 2:05:37 PM1/16/15
to blin...@chromium.org, kenneth.ch...@gmail.com, mar...@marcosc.com
Apologies if this question has already been asked.

How does this relate to navigator.standalone? Will that always be true when display-mode is standalone? 

Also I presume the manifest display-mode is only a preference and UAs may ignore it and display something different? I can imagine cases where for product reasons we may want to do that, for example when web apps are added to the homescreen of a device we may want to always launch them in standalone (unless display-mode is set to fullscreen), regardless of the manifest.

Kenneth Rohde Christiansen

unread,
Jan 17, 2015, 5:32:27 AM1/17/15
to Chris Harrelson, blink-dev, mar...@marcosc.com
Answer below

On Fri Jan 16 2015 at 6:48:56 PM Chris Harrelson <chri...@google.com> wrote:
On Thu Jan 15 2015 at 3:41:06 AM Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:
Primary eng emails

Spec

Summary
Add a media query feature for detecting the display mode used when launching/loading the web app. Default mode is 'browser' but other modes can be declared using a manifest: http://updates.html5rocks.com/2014/11/Support-for-installable-web-apps-with-webapp-manifest-in-chrome-38-for-Android

Motivation
Developers would like to be able to detect from JS and be able to use different styling depending on the display mode set in the manifest file.

This enables various use-cases such as 

* decide whether to promote "Add to homescreen";
* offer a different UI (like back button when in 'standalone');
* have data required to record usage metrics.

Similar JS API already exists on iOS navigator.standalone and web developers have requested the same for the new Web Application Manifest.



Compatibility Risk
Public support for the Web Application Manifest have been given by Chrome, Firefox and IE. Web developers have expressed interest in this addition and it has support from the developers working on Web Application Manifest at Google and Mozilla according to the GitHub issues.

Describe the degree of compatibility risk you believe this change poses
Low - It has been requested and discussed for a long time. iOS provides similar means. The 'display' field in the manifest is already shipping in Chrome so name is unlikely to change.

Ongoing technical constraints
None

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS, and Android)?

There are six platforms: WebView was recently added. Do you intend to support it? If so, what would the semantics be?

The idea is that the display mode is only applied as part of applying the manifest (http://w3c.github.io/manifest/#applying-the-manifest) which happens when the web app is added to the home screen and later launched from there (ie Android home screen or Chrome OS launcher).

That means that the value should [as specced] be 'browser' for the content being shown by the WebView.

That said, frameworks using the WebView as an app runtime (like Cordova and Crosswalk) probably want to be able to set the display mode. Crosswalk already uses the Web Application Manifest for building packages, but it doesn't use the WebView.

If there is interest we can add an API to the content module that allows setting the value programmatically. I know that Crosswalk would like this ability.

Kenneth

Kenneth Rohde Christiansen

unread,
Jan 17, 2015, 5:39:09 AM1/17/15
to owe...@google.com, blin...@chromium.org, mar...@marcosc.com
navigator.standalone is a non-standard used by Safari. The (display-mode:...) media query feature is a standardization of this, which also allows querying from JS using matchMedia.

To answer the second question, I am quoting the spec:

"A display mode represents how developers would like the user agent to present the web application to a user (e.g., in fullscreen). Display modes correspond to user interface (UI) metaphors and functionality in use on a given platform. The UI conventions of the display modes are purely advisory and implementers are free to interpret them how they best see fit."

That said, if the author said the display to "browser", the application presumable doesn't work well as standalone and would require back and forward buttons in the browser UI.

Cheers
Kenneth

Marcos Caceres

unread,
Jan 18, 2015, 11:52:09 PM1/18/15
to owe...@google.com, Kenneth Rohde Christiansen, blin...@chromium.org



On January 17, 2015 at 8:39:06 PM, Kenneth Rohde Christiansen (kenneth.ch...@gmail.com) wrote:
> > navigator.standalone is a non-standard used by Safari. The
> (display-mode:...) media query feature is a standardization
> of this, which also allows querying from JS using matchMedia.

What we are trying to avoid is scripts directly detecting if an application has been "installed" - mostly because we don't want to end up with annoying "Install my app", or "add me to your home screen" banners all over the web ([1] describes the problem in detail, and shows examples of how bad it can get). 

The idea being that a user can manually put an application into a display mode independently of the manifest's display mode (e.g., as one does in Chrome Desktop for Mac by using either selecting "View > Enter Full Screen", which is really "standalone", or "View > Enter Presentation Mode" which is actually fullscreen as defined in the spec).  

It does, however, mean that browsers will need to reward developers who do the right things(tm) through "installability signals" [2] by letting users know that their apps can be installed - and by providing a nice user experience with the installation process. 

[1] https://github.com/w3c-webmob/installable-webapps/tree/gh-pages/ios_standalone#add-to-home-screen
[2] http://w3c.github.io/manifest/#installability-signals


Ben Wells

unread,
Jan 19, 2015, 6:29:00 PM1/19/15
to Marcos Caceres, owe...@google.com, Kenneth Rohde Christiansen, blin...@chromium.org
The standalone mode is currently available on the Windows and Linux desktop platforms, and is being added to ChromeOS and Mac. Additionally a minimal-ui mode is also being added to ChromeOS.

Will the implementation handle the existing desktop standalone mode? I assume I'll need to do something to reflect the minimal-ui mode.

On Mon Jan 19 2015 at 3:52:07 PM Marcos Caceres <mar...@marcosc.com> wrote:

Kenneth Rohde Christiansen

unread,
Jan 20, 2015, 4:27:54 AM1/20/15
to Ben Wells, Marcos Caceres, owe...@google.com, blin...@chromium.org
It would make a lot of sense to have Chrome Apps launch mode reflected in display-mode as well.

I will look at adding a way to set the mode programmatically from the content module, when this feature get the remaining LGTM :-)

Cheers
Kenneth

PhistucK

unread,
Jan 20, 2015, 6:22:09 AM1/20/15
to Kenneth Rohde Christiansen, Ben Wells, Marcos Caceres, owe...@google.com, blink-dev
Not only Chrome applications. There is the application shortcut feature (Wrench->More tools->Create application shortcuts...), which is unrelated to Chrome applications/extensions/whatever. I am not sure this feature exists everywhere (maybe only on Windows, maybe not). This is the standalone mode, I believe.
And should kiosk mode be the fullscreen mode?


☆PhistucK

Ben Wells

unread,
Jan 20, 2015, 7:19:15 AM1/20/15
to PhistucK, Kenneth Rohde Christiansen, Marcos Caceres, owe...@google.com, blink-dev
On Tue Jan 20 2015 at 22:22:06 PhistucK <phis...@gmail.com> wrote:
Not only Chrome applications. There is the application shortcut feature (Wrench->More tools->Create application shortcuts...), which is unrelated to Chrome applications/extensions/whatever. I am not sure this feature exists everywhere (maybe only on Windows, maybe not). This is the standalone mode, I believe.

Yep, that's what I was referring to. It is currently available on Windows and Linux. In M42 it should also become available on ChromeOS (where it will be more like a minimal-ui from the manifest spec, as there will be a back button and wrench menu in the caption area) and Mac.

Chris Harrelson

unread,
Jan 20, 2015, 1:04:43 PM1/20/15
to Ben Wells, PhistucK, Kenneth Rohde Christiansen, Marcos Caceres, owe...@google.com, blink-dev
LGTM
Reply all
Reply to author
Forward
0 new messages