CSS media features for display modes #155

Closed
marcoscaceres opened this Issue Feb 24, 2014 · 6 comments

Projects

None yet

2 participants

@marcoscaceres
Member

The primary use cases for display modes are styling related. As such, it would be beneficial for developers if display modes were a CSS media feature:

@media all and (display-mode: standalone){
  /*Add/remove standalone things */ 
}
@marcoscaceres marcoscaceres added this to the Future version milestone Feb 24, 2014
@marcoscaceres
Member

To detect minimal-ui on iOS, developers will have to do the following.

@media (device-height: 568px) and (height: 529px),
(device-height: 480px) and (height: 441px) {
/* minimal-ui is active */
}
@media (device-height: 568px) and (height: 460px),
(device-height: 480px) and (height: 372px) {
/* normal mode, minimal-ui inactive */
}

This doesn't scale and it's error prone. It would only works on devices that are an iPhone.

@marcoscaceres
Member

(updated comment above)

@marcoscaceres marcoscaceres modified the milestone: Future version Mar 17, 2014
@marcoscaceres marcoscaceres added the V2 label May 23, 2014
@laurentperez

Out of curiosity, why not choose something like window.navigator.manifest or reuse <link rel="manifest" href="...">?

Using @media all and (display-mode: standalone) introduces a dependency on CSS and may produce a FOUC

Reusing link rel could perhaps give a hint to the preload scanner to avoid a FOUC and window.navigator.manifest could expose status fields like applicationCache did.

@marcoscaceres
Member

I'm not sure what you mean by "reuse <link rel="manifest" href="...">"?

Using @media all and (display-mode: standalone) introduces a dependency on CSS and may produce a FOUC

Not sure why it would produce a FOUC? Also, most uses of window.navigator.standalone (Apple's equiv.) are used to change style. Better to move this to CSS IMO.

Reusing link rel could perhaps give a hint to the preload scanner to avoid a FOUC and window.navigator.manifest could expose status fields like applicationCache did.

I'm not really following? We use link rel=manifest already in the spec... but I'm still not really sure what you are proposing.

@laurentperez

Sorry, my comment was in response to the "My requirements for the "Manifest for Web Applications"" email on public-webapps by Mark, you referenced this github issue when he wrote :

It is unclear to me whether the developer can determine if the manifest has been read,
and which parts of the manifest definition have taken effect. This is useful in order
to customise content. For example determining if the html is running in a web browser
(and therefore no settings have taken effect), so orientation may need to be handled
differently. There are other examples for display mode etc.

I now realize this github issue is really about display mode detection and not about "if the manifest has been read". I was referencing appcache status codes because looking at the manifest spec, I do not see a way to tell if the manifest has been read.

If the preload scanner looks for link rel="manifest", it can create an object like window.navigator.manifest and this object could expose the display modes directly, or any member, very early. If CSS is required to detect the display modes it may produce a FOUC if this CSS is loaded late. The preload scanner is not - currently - a MQ parser and it has no way to prioritize the standalone CSS styles to avoid a FOUC. Also the preload scanner could preload the icons member of the manifest, or a spash screen member in the future.

You are correct when writing that window.navigation.standalone is used to change the style.

@marcoscaceres marcoscaceres added v3 and removed V2 labels Nov 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment