RE: Presentation API changes proposal

Hi Mark, Thx for your feedback I like your idea to allow window as a root. This is one possibility to cover mirroring (besides screen extension) using requestShow, which is currently out of scope of the Presentation API (Please refer to the ‘Presentation API usage: Mirroring vs Extension’ thread).
I think a unified API for both mirroring and extension is easier to use from developer perspective even if there are other ways to realize screen mirroring.

Best regards,
Louay

From: Mark Finkle [mailto:mfinkle@mozilla.com]
Sent: Freitag, 10. Januar 2014 14:52
To: Bassbouss, Louay
Cc: Anssi Kostiainen; Anton Vayvod; public-webscreens@w3c.org; Miguel Garcia; Peter Beverloo
Subject: Re: Presentation API changes proposal



________________________________
Promise requestShow(optional DOMString url = "about:blank" | DOMElement elem, optional boolean infinitePlay = false);



In case the first parameter is a DOM Element, The DOM Subtree starting by this element will be displayed on the second screen. Any manipulation  in the DOM subtree on the original document (first screen device) results in updating the copy on the second screen (MutationObservers[1] is one possible way to observe changes). Updates can be sent for example over a RPCDataChannel.
I'm a little worried about allowing arbitrary DOM subtrees. Other DOM elements can float over the assumed "viewport" of the subtree, making it hard to figure out what exactly to mirror. I also think it could be a bit more difficult to implement.

On the other hand, I like the idea of using the window as a root. Either the hidden secondary window or the current main window (the tab sharing concept).