#767: Multi-Screen Window Placement on the Web - Initiating Multi-Screen Experiences

Visit on Github.

Opened Aug 31, 2022

Wotcher TAG!

I'm requesting a TAG review of Multi-Screen Window Placement on the Web - Initiating Multi-Screen Experiences.

This proposal introduces a Multi-Screen Window Placement API enhancement that would allow web applications to initiate a multi-screen experience from a single user activation.

  • Explainer¹ (minimally containing user needs and example code): Explainer
  • User research: Feature Request
  • Security and Privacy self-review²: Questionnaire
  • GitHub repo (if you prefer feedback filed there): Repo
  • Primary contacts (and their relationship to the specification):
    • Mike Wasserman (@michaelwasserman), [Google] (Spec editor)
    • Joshua Bell (@inexorabletash), [Google] (Spec editor)
    • Anssi Kostiainen (@anssiko), [Intel] (Second Screen WG co-chair)
    • Louay Bassbouss (@louaybassbouss), [Fraunhofer FOKUS] (Second Screen WG co-chair)
  • Organization/project driving the design: Google
  • External status/issue trackers for this feature (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5173162437246976

Further details:

  • [✓] I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): Second Screen WG
  • The group where standardization of this work is intended to be done ("unknown" if not known): Second Screen WG
  • Existing major pieces of multi-stakeholder review or discussion of this design: Mozilla standards position issue and Prior TAG review request
  • Major unresolved issues with or opposition to this design: Mozilla security considerations (see above), TAG request for a new design review (see above)
  • This work is being funded by: Google

You should also know that...

I appreciate your time reviewing this proposal; thank you!

We'd prefer the TAG provide feedback as (please delete all but the desired option): 💬 leave review feedback as a comment in this issue and @-notify @michaelwasserman

Discussions

2022-10-17

Minutes

Dan: I note it's shipping in Chrome 104.

Dan: the work they've done addresses concerns that were raised by the TAG previously...

2022-10-31

Minutes

Dan: two weeks ago we asked for information, they said it shouldn't have been marked as early but they appreciate TAG feedback including [specific question].

2022-11-28

Minutes

Dan: shipping, early, no signals from other engines

Amy: A couple of still-open moz standards positions 636 and 542... not closed, lots of back and forth about security issues, not looking great on surface-level analysis.

Dan: "There is no obvious way for a web application to detect support for the proposed feature." Doesn't sound great.

Rossen: what does it mean for the primary contact to be the incubation group?

Amy: Also looks like there was a conversation at TPAC...

Rossen: One thing: how would I map parts of the elements' subtree - hello world e.g. centered inisde of the element. How would a screen reader get the relative coordinates of that element in respect to the screen reader? In order for the screen reader to draw its focus rectangle it would need to know where the element is. That location is usually relative to the window... since AT API allows you to keep traversing up to the screen you will know you're relative to a screen but if you're part of a document how would you know you're relative to a different screen. I get how it works with multi-windows - but in here you have essentially one window.

<blockquote> Hi @michaelwasserman yes probably it would have been better to request a spec review for something this far along in the process. We're concerned about the lack of multi-stakeholder support or signals thereof. We note extensive discussion on the security considerations in mozilla/standards-positions [#636](https://github.com/mozilla/standards-positions/issues/636) and [#542](https://github.com/mozilla/standards-positions/issues/542) which don't seem to have come to resolution yet. Any update on this or info on other implementers supporting / working on this? Lack of feature detection is also concerning and goes against our [design principle](https://w3ctag.github.io/design-principles/#feature-detect) on detectability. </blockquote>

posted

2023-02-27

Minutes

Max: no feedback yet.

2023-03-06

Minutes

Dan: michael responded to our request and has indicated many things being worked on - responsive to TAG feedback.

Hi @michaelwasserman I see your virtual meeting happened yesterday - sorry we didn't get you feedback prior to that.  Based on your comments it looks like the issues TAG has raised are being considered.  On this basis we're happy to close this review as "satisfied".  

Regarding opening up a new review request for the entire spec, I think we already had some signifigant discussion in [issue 602](https://github.com/w3ctag/design-reviews/issues/602).  I think it may be appropriate to open up a new issue as part of wide review when the spec goes to CR.