search

w3c / presentation-api

Presentation API
https://www.w3.org/TR/presentation-api/
Other
71 stars 39 forks source link

Presentation display capability detection #348

Open markafoltz opened 8 years ago

markafoltz commented 8 years ago

This is a placeholder for discussion of capability detection for presentation displays. Basically, the controller may want to provide more detailed constraints on the display through the API to further filter the list of screens shown to the user.

For example:

This discussion is to brainstorm ways to improve this experience, while addressing privacy and implementation concerns.

Related: https://github.com/WICG/media-capabilities (not yet drafted)

markafoltz commented 8 years ago

CC @mounirlamouri

mounirlamouri commented 8 years ago

Would it make sense to have an extended constructor for PresentationRequest that takes a list of constraints that could include these information?

tidoust commented 8 years ago

For reference, see related discussion at TPAC

markafoltz commented 7 years ago

Would be good to analyze this again with respect to MediaCapabilities.

markafoltz commented 6 years ago

The feedback from #444 suggests that there could be a use case for "presenting" the same page onto a VR headset, which would require knowing if there is a VR headset available for presentation. We should pick this up based on the outcome of that discussion.

anssiko commented 6 years ago

Closing this per F2F decision, if concerns or new information emerges we can reopen.

markafoltz commented 6 years ago

Had a recent conversation with a user who was surprised they could present a visual document to an audio-only networked speaker, which is possible with the current API.

Meanwhile, presenting audio-only pages to these devices makes perfect sense.

With URL-based filtering, we would need the receiver to know in advance which documents required video output and which do not. I would consider a change allow the PresentationRequest to note whether video or audio were required to be a good usability improvement.

louaybassbouss commented 6 years ago

+1 but I am wondering how it works for 2-UA mode. Do you expect that the receiver URL points to an HTML page that plays an audio (in this case the audio receiver device needs to parse the receiver page/run Javascript ??) or directly to the audio itself?

markafoltz commented 6 years ago

Yes :smile: Cast applications that run on Cast for Audio/Assistant speakers work exactly this way.