RE: Presentation API changes proposal

Hi Ansi,

My proposal addresses a new mechanism rather than new use cases. Using this mechanism, developers don't need necessary to put the second screen content in an separate html document and control it e.g. using post messages. There is only one Application Context (on the first screen device). Developer manipulates the DOM as usual using DOM operations. There are two ways realization:
- Browser on first screen device captures the requested DOM element and sends the stream to the second screen (e.g. by using technologies addressed here http://webscreens.github.io/presentation-api/#introduction ) 
- Browser on first screen device sends changes of the requested DOM element to the second screen and a Browser Engine on the second screen renders the content. 

The proposal is relevant for all use cases mentioned here http://webscreens.github.io/presentation-api/#use-cases . Below is a template for the slides example:

<html>
<body>
	<div id="controls"> ... </div>
	<div style="display: 'none'">
		<div id="slides"> ... </div>
	</div>
	<script>
		var slidesElem = document.getElementById("slides");
		requestShow(slidesElem);
		// manipulation of slides DOM Subtree after requestShow results in 
		// updating the copy on the second screen. But this is hidden for developer. 
		slidesElem.appendChild(...)
	</script>
</body>
</html>

For gaming use cases please refer to this paper (http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6605845 ) I already submitted this year. 

I hope this answers you question :)

Best regards,
Louay

-----Original Message-----
From: Kostiainen, Anssi [mailto:anssi.kostiainen@intel.com] 
Sent: Mittwoch, 8. Januar 2014 14:09
To: Bassbouss, Louay
Cc: Anton Vayvod; public-webscreens@w3c.org; Miguel Garcia; Peter Beverloo
Subject: Re: Presentation API changes proposal

Hi Louay,

On 08 Jan 2014, at 13:26, Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de> wrote:

> Dear Anton, Kostiainen,
>  
> I also like the proposal of Anton.   We have also a proposal I merged it in the spec propose by Anton:
>  
> 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.

Thanks for your proposal. Do you have a use case in mind that requires displaying a subtree of the DOM on the second screen?

Thanks,

-Anssi

> [1] http://www.w3.org/TR/dom/#mutation-observers

Received on Wednesday, 8 January 2014 14:05:18 UTC