Support window preferred/initial (minimal?) sizes

[kenchris]

There is growing interesting in Progressive Web Apps on desktop, both with Crosswalk, Manifoldjs, but developers are also asking for some support natively in browsers.

Desktop OSes have freeform windows support and with Android potentially getting support for this (http://arstechnica.com/gadgets/2016/03/this-is-android-ns-freeform-window-mode/), I think it is time to look at adding such support to the manifest format.

Crosswalk already supports window width and height.

ChromeApps supports something similar (though it goes through a method)

https://developer.chrome.com/apps/app_codelab_basics 👍

When the Chrome App is launched, chrome.app.window.create() will create a new window using a basic HTML page (index.html) as the source. You will create the HTML view in the next step.

chrome.app.window.create('index.html', {
  id: 'main',
  bounds: { width: 620, height: 500 }
});

https://developer.chrome.com/apps/app_window#type-BoundsSpecification

integer (optional) left 
The X coordinate of the content or window.

integer (optional) top  
The Y coordinate of the content or window.

integer (optional) width    
The width of the content or window.

integer (optional) height   
The height of the content or window.

integer (optional) minWidth 
The minimum width of the content or window.

integer (optional) minHeight    
The minimum height of the content or window.

integer (optional) maxWidth 
The maximum width of the content or window.

integer (optional) maxHeight    
The maximum height of the content or window.

[kenchris]

@RobDolinMS @owencm @PaulKinlan @boyofgreen ^

[PaulKinlan]

There was some discussion about this in the early phases of Chrome Apps. iirc the consensus was to not have it in the manifest because it wasn't flexible enough for all the different screen-sizes and constraints that the developer has which is why it was left to the window.create method to control how windows would be opened.

Do you have links to where people are asking for it in CrossWalk etc and their requirements.

[kenchris]

I emailed people who might remember.

ChromeApps work differently because they don't show any UI (event page) by default, so they can all call a method. This is not how PWAs work.

I do think there is a need to be able to set some sane default sizes. For one, a calculator would probably not launch and fill up 80% of the screen, though it might show more advanced features if given more real-estate.

A calculator like that might be useless with its UI when it is smaller than a given size :-) like 30px * 30px would probably not work :-) and it might have a size, where beyond that, it is just stretching and not making more use of the space.

I think that the top and left arguments are quite useless given how window management works today and especially when the developer have no way of knowing the size of the screen when putting these values in the manifest.

[kenchris]

I just wanted to point out that PWAs generally should support any sizes and be responsive, but I do think that a preferred size is quite valuable

• a calculator doesn't require much size and would usually be use on top of other apps, same would go for many chat apps - both the calculator and the chat app can easily work well on bigger sizes. I would prefer these to start at around the standard size of phone apps, but I wouldn't want all apps to start at that size on my desktop.
• a small radio player (like the music player on chrome os) might want to stay small and mostly out of the way
• some apps simply makes no sense when too small (smaller than a phone screen) like a spreadsheet app. Currently apps can create a media query and say "please make me bigger". Personally, I think the OS should probably have a default minimum size, which apps could override if they want to be smaller.

[beaufortfrancois]

I personally think the web manifest is not the right place for these attributes. I wonder if that should belong to the serviceWorker scope. Something like this below seems more appropriate:

let url = 'https://example.com';
let options = {
  outerBounds: {
    width: 256,
    height: 256
  }
};

client.navigate(url, options).then(function(windowClient) {
  console.log(windowClient.outerBounds.width);
  console.log(windowClient.outerBounds.height);
});

@jakearchibald any thoughts?

[kenchris]

That is an interesting idea and that should be pretty flexible.

[jakearchibald]

A few months ago @slightlyoff @domenic & I threw around some ideas around a "launch" event, which would let you decide how an ambiguous navigation should be handled.

An ambiguous navigation basically means anything where the user didn't dictate how the navigation should be handled. Eg long-pressing and selecting "open in new tab" is expressed intent from the user, but clicking a link in a native app isn't.

If you get a "launch" event, you can direct the navigation at an existing client, or open a new window for it. This would let you decide if you want to operate a multi or single window app.

This feature, plus a few options to clients.openWindow would cover the proposal in this ticket.

Having said that, I'm not sure who we'd want to be able to do this. As a user I often find it annoying when something decides to be small on a massive monitor or vice versa. Might be restricted to home screen'd apps, which takes me back to the manifest 😄

[kenchris]

Well, apps might want to remember their last sizes and position and as I said above, app like calculator usually wouldn't not want to launch in large windows. I think it is useful, but only allowing it for apps which have been added to a home screen is fine with me.

We might also make it clear by calling these hints.

[boyofgreen]

In Windows 10 we also have a concept of preferred window size, but it can always be overwritten by the user. One thing that we do enforce in a "minimum" window size, which i think would fall into this. We want to know what the minimum size the app is workable at

[mgiuca]

Hey,

@hwikyounglee independently asked about this. I do think this could easily be a declarative thing in the manifest:

{
    "default_size": "640x480"
}

re-using the "sizes" syntax in ImageResource. This would be a hint to the UA what the default size of the window would be, with the explicit intention of letting the user resize the window and remember that new size (which is why it's not good to use an imperative API).

There is already the Window.resizeTo method which lets the developer modify the app window's size explicitly, but I think we want one that lets the user change the size of the window without being forced back in every time they re-open it.

I don't think making this part of the Service Worker launch event makes sense. It's a bit heavy-handed to require the developer to override navigation just to set a preferred window size.

[aarongustafson]

I’m not averse to a simple approach to this (like what @mgiuca mentioned) with the caveat that browsers should retain the user’s preference if they’ve resized the window on their own.

I do see some use for this in the screen enumeration and window placement scenarios we discussed at TPAC yesterday (e.g. financial dashboards), but those are far more complex, with multiple windows to control and arrange with respect to one another. I like the idea of declaratively establishing the organization of multiple windows (or even one), but I think I’d prefer to create some sort of external definition (similar to ImageResource) that could be pulled into a manifest rather than have it be defined in the manifest spec itself.

Syntax wise, it could be something like this:

"windows": [{
  "name": "foo",
  "size": "640x480",
  "position": { "x": "100", "y": "100" }
},
{
  "name": "bar",
  "url": "/tools/panel.html",
  "size": "640x480",
  "position": { "x": "100", "y": "100" }
}]

On opening an app for the first time, it could loop through the windows and generate and place each one. Without a url property, the start_url would be used. URLs would need to be in scope (naturally) and name (which might be optional) could be used for cross-window communication. We could also extend position to include z for spacial apps.

[nik3daz]

One idea that I've had on this topic is to use the document's tag's size and size constraints as PWA Window size constraints.

i.e

html {
  min-width: 300px;
  min-height: 400px;
  max-height: 900px;
}

would apply to the PWA Window too.

We'd still probably need a manifest fallback for first run and initial size, but this allows PWAs to dynamically apply different size constraints e.g a Mail App might want a different min-size for a Compose View vs a List View. Crazier still, a site might want to animate the window size through CSS e.g clicking on an item in the List View changes the window size via a CSS transition to expand a Content View.

I'm sure there are issues here (e.g content size or window size? maybe use box-sizing property?), but the core point is that the CSS engine has powerful box sizing primitives, and it would be cool to let PWAs express the behavior of their 'box' through these existing semantics.

[christianliebel]

@nik3daz Adding CSS for html has side effects which affect the normal rendering of the website even when not being installed. The Web App Manifest is the central place for defining the appearance and behavior of the installed app. If we want to have that feature, it belongs there from my point of view. However, we could allow CSS units in the manifest, e.g.

{
  "size": { "width": "600px", "height": "480px" }
}

.cc @aarongustafson

[tomayac]

For widget-like PWAs that potentially have two modus operandi, for example, a calculator that is simple in portrait, but scientific in landscape mode, we'd need more than one preferred size.

I agree that manual overriding of such preferred size should be possible and respected. If for whatever reason one wants to have a PWA in a "too big" window, one should be able to do so.

[marcoscaceres]

Closing for now until we get more interest...

[hanguokai]

Is there a final & available solution to this problem for standalone-display on desktop? For example, "start_sizes": "800x600", "single_window": "true/false".

[leopsidom]

It would be great if we can support this. Do we have a thread to track the progress of this ?