w3c / window-management

Window Management API
https://www.w3.org/TR/window-management/
Other
97 stars 25 forks source link

Scope of the initial proposal #15

Closed michaelwasserman closed 4 years ago

michaelwasserman commented 4 years ago

I recently limited the initial scope of the proposal, by scaling back the current goals and moving a lot of possible future goals to a separate additional explorations document.

Any feedback about that change, thoughts regarding alternative new APIs, or general advice about scoping the proposal is welcome; thanks!

anssiko commented 4 years ago

Alternative new APIs states:

This could enable further deprecation of existing window placement APIs, which have been prone to abuse and inconsistencies over time. There are several active and forthcoming proposals to limit or deprecate existing window placement APIs.

Can you define existing window placement APIs?

michaelwasserman commented 4 years ago

Sure! The set of existing 'window placement' interfaces I'm referring to there includes:

I will include this in the Explainer, which is still undergoing active refinement. The comment about abuse and inconsistency, which may motivate explorations of deprecation, is specifically referring to the Window.open() feature string bounds, and window.[move|resize][To|By](). Thanks for the question! Hope that helps!

MichaelKetting commented 4 years ago

@michaelwasserman I'm not sure if I should post this here or start a new ticket. This is in response to https://bugs.chromium.org/p/chromium/issues/detail?id=137681#c117

Use Case: Enterprise applications often use multiple windows and users wish to preserve their window layout between individual work items. In our case, this is about a document management feature with the preview being opened in a new window. Depending on the user's desktop, the user may move this preview window onto the secondary screen. Now, when the user starts work on a new item, the preview should again be opened on the secondary screen at the same positon. Right now, this behavior is broken when using Chromium-based browsers, opening the windows on top of each other and forcing the users to switch focus, re-align the windows, and only then continue their work.

Interstingly enough, it appears that enabling the feature flag also restore's the original window.open/moveto behavior. Of course, it's not possible to roll out an experimental feature into the field.

The best outcome would be to just be able to use the existing APIs the same way they worked before this feature was removed in Chrome sometime in 2012 (based on the bugtracker ticket). Providing this functionality using a new API is workable, but will require an update to the application just to make it work with Chromium-based browsers.

Given that Microsoft is now rolling out the Chromium-based version of Edge and will include this version in Windows 10 v20H2, this becomes a particularily blocking issue when it comes to moving away from Microsoft Internet Explorer to more recent browsers. Do you also happen to have a time frame in mind when this feature will become available without a feature flag in the Chromium-options?

hober commented 4 years ago

Hi, I got here from w3ctag/design-reviews#413.

I think the initial proposal is pretty well-scoped. I encourage you to take Baby Steps—see the current scope through to standardization, then bite of the next piece, then the next, and the next.

michaelwasserman commented 4 years ago

@MichaelKetting the current proposal would enable saving and restoring cross-screen window placements without new APIs, but perhaps gated on a new permission. See the saveOpenWindows() and restoreSavedWindows() example in this section of the updated explainer. Chrome's highly speculative and aspirational time frame is origin trial in M-86 and broader availability in M-89.

@hober Thanks for sharing that insight and post. I believe the updated proposal is narrowing in on a very solid Baby Step to extend existing screen information and window placement capabilities for multi-screen devices. I look forward to further refinements and possible standardization.

I'm going to close this issue, but welcome more feedback anytime; thanks!