Skip to content

Instantly share code, notes, and snippets.

@richtr

richtr/gist:2235fdae25c74186297d

Last active August 29, 2015 14:13
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save richtr/2235fdae25c74186297d to your computer and use it in GitHub Desktop.
Save richtr/2235fdae25c74186297d to your computer and use it in GitHub Desktop.
Download ZIP
General considerations for Media Focus scoping, lifecycle and events
Raw
gistfile1.md

Media Focus Scope

  • At what level should Media Focus be requested and granted/revoked?

    • Per Tab(s)
      • Per Origin(s)
        • Per Document(s)
          • Per Media Grouping(s)
            • Per Media Object(s)

  • High-level vs. Low-level scope - what are the pros and cons of setting the media focus scope at these different levels? Do we want audio focus to be set and applied implicitly to tab/document/origin content or explicitly to in-page media groupings or elements?

  • Should a UA enforce media output pausing/termination when a scope loses media focus?

    • Option A: the user agent MUST pause/stop all related media output when its scope loses media focus.
    • Option B: we leave it up to a web app to enforce the pause/stop of all related media output when its scope loses media focus.

Media Focus Lifecycle

  • When can media focus be requested by a web app?

    • Option A: At any time.
    • Option B: When media output starts.
    • Option C: Only when some media output has been started and is playing.

  • When should media focus be granted to a web app?

    • Option A: Immediately when media focus is requested. This does not ensure we actually have any media output and is incompatible with iOS Remote Control Events model.
    • Option B: When media output has started within the scope of the request for media focus. This is the only way to actually obtain media focus in the iOS Remote Control Events model.

  • When should media focus be revoked from a web app?

    • Option A: Never, unless a.) media focus is explicitly released by a web app or b.) the web app is terminated in some way (e.g. the user closes the tab or navigates to another web page within the tab) or c.) another web app requests and gains control of the media focus.
    • Option B: When media output ends within the scope of the current media focus. Difficult to establish exactly when media output is finished. We could use audio graph heuristics to decide if media output has ended but it may, for example, just be a delayed transition to a next track in a playlist.

  • Can a web app re-gain lost media focus? Do web apps need to re-request media focus or can the UA automatically re-grant media focus to a scope that was previously granted media focus?

    • e.g. I open a first tab and go to 'play.spotify.com' and then start music playback. Then I open a second tab and go to 'html5.grooveshark.com' and start playing content. Both web apps are requesting media focus. Initially media focus will be granted to some scoped media content the first tab. Once the second tab requests media focus it will then be transferred to some scoped media content within this tab. Now if the user goes back to the first tab and resumes listening to some audio there should the media focus be returned to the first tab? If so, should that happen automatically or be manually re-requested by the first tab?

  • How does media focus get transferred from one scope to the next scope?

    • Option A: When another scope requests media focus they immediately become the owner of the media focus. The previous owner of the media focus will have its media focus revoked.
    • Option B: When another scope begins media output (and they have requested media focus) then they become the owner of the media focus. The previous owner of the media focus will have its media focus revoked.
    • Option C: When media out is invoked by the user through some UI controls. When media output starts on a scope then media focus is transferred to this scope and revoked from the previous scope.

Media Key Capabilities

  • Does a web app need to tell the UA which media keys it supports? Can different web apps support different combinations of media keys?

    • e.g. A web app wants to play one audio track. Therefore it doesn't support playlists and therefore we should not display and/or enable media key seeking or track skipping.
    • e.g. A web app wants to play multiple tracks (i.e. it has a playlist). Therefore we should support any available track skipping media keys and the web app should be able to respond to those keys being pressed.

  • What should 'skip to next/previous' track mean in the context of web-based media focus?

    • Option A: This can be defined by each web app seperately.
    • Option B: The behavior of next/previous skipping is defined and enforced at the UA level.

Media Key Events

  • Do we want to support media 'seek' keys and if so how should media seeking be supported in a Media Controls API?
    • NOTE: seek behaviour is not available from the iOS homescreen unless an app routes its audio output through the default music app.
    • e.g. If a page's media is not seekable (e.g. it's a real-time video stream) then we should not allow forward or backward seeking media keys in any media controls and we should also not fire seek events toward the web app.
    • e.g. If a page's media is seekable (e.g. it's a music track) then we should enable forward or backward seeking media keys in any media controls and we should also fire seek events toward the web app. In addition we need a way to communicate the seeked position back to the web app, potentially with regular progress events that track the requested seek position in the media content.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment