Re: Updated Presentation API WebIDL - call for review

Hi MarkFo, All,

On 15 Apr 2014, at 01:38, mark a. foltz <mfoltz@google.com> wrote:

> Thanks for the detailed response and sorry for the late reply - 
> 
> So it seems the approach that is satisfactory is to leave the placement of the screen selection dialog up to the user agent.  If the UA wishes to place the dialog within the viewport (as mobile Safari does with <input type="file">) it can, but that's not going to be required by any part of the Presentation API.

Agreed. To reach an agreement on this issue — does anyone object [with good reasons :)] to us leaving the screen selection dialog positioning up to the UA?

[...]

> I'm certainly not opposed to browsers using context menus if they feel that's the best UX to expose this feature, as long as we're not making it an implementation requirement.  I think it might make sense in certain contexts, such as the context menu for a <video> element, but not as a general mechanism to open up to the Web.

I think we should not make it an implementation requirement, it just provides web developers a means to invoke requestSession() in the context of the element. Alternative would be to use a <button> positioned underneath the <video> element, for example.

> For example, how would the site be able to create markup to populate the menu without being able to enumerate all available screens?

The site would not be able to get the enumeration, rather the *UA* could present the enumeration in the context of the click that invoked requestSession() if it wishes to, similarly to the iPad <input type=file> discussed earlier. This would be an implementation detail, and some implementations might prefer alternative mechanisms, such as displaying the enumeration in the chrome in an infobar as per the currently prevalent practice.

Btw. we’re discussing an analogous enumeration issue in another group in the context of getUserMedia() and getMediaDevices() and people have concerns:

  https://www.w3.org/Bugs/Public/show_bug.cgi?id=25245

Allowing web content to access the enumeration of [hardware] devices is a generic issue that is shared with other privacy-sensitive APIs on the platform. I suggest we do not try to solve this issue in isolation. When the getMediaDevices() issue is resolved we could reuse that, and meanwhile more forward in other areas of the API.

Does that sound reasonable?

To summarize, I’d like the group to agree on the following:

1) The screen selection dialog positioning is up to the implementation.
2) Web content cannot get access to the enumeration of the screens, rather the UA mediates the selection and passes a PresentationSession to the web content as per the user’s selection.

Please let us know if you have concerns with the above so we can close these issues.

Thanks,

-Anssi

Received on Thursday, 17 April 2014 09:40:15 UTC