It would be possible to support something like XSPF http://xspf.org/ or mediaRSS http://www.rssboard.org/media-rss could be supported as input format to media elements. It's an indirection though.

An alternative is to run your own in JavaScript using the media.load() function on a list of files.

The biggest question comes when (and if) we want to support standard playlist functionality in browsers, such as forward to next file/rewind to previous - then we need additions to the JavaScript API and possibly to the @controls user controls.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: none yet
Rationale: Playlists are similar to the media element synchronisation problem, except that instead of having one timeline that is synchronised across multiple elements, it's handling switching from one to another in real time. I think we'll probably have some sort of Controller object that gets a list of media elements and a configuration for how they relate. That's not for this version though.

This bug was cloned to create HTML WG bug 19035.

So what exactly is needed here?

It would be helpful to have a good description of the use cases and requirements.

I think it's important to have the playlist data specified by some element (and sub elements) like:

<playlist>
    <track>
        <source> for vorbis
        <source> for mp3
    </track>
    <track>
    <track>
        <source> for vorbis
        <source> for mp3
    </track>
    </track>
</playlist>

With xspf for example, you can parse the XML and use the data to create a bunch of HTML elements to render and interact (via JS events etc.) with the playlist. But, what would be way more straightforward is to have a playlist element to specify the data so the browser itself sets up the rendering and interaction of the element.

For example:

* HTMLPlaylistElement via document.createElement("playlist") and new Playlist()

* HTMLTrackElemenet via document.createElement("track") and new Track();

* <track> will contain one or more <source> elements.

* <track> can contain a few elements for meta data like artist, title etc.

* The playlist object would have prevTrack() and nextTrack() functions and 'load' and 'trackchange" events. removeTrack(range) would be good too.

* A "playlistchanged" event might be good too to save a snapshot of the playlist for when the user returns to the page.

* A playlist file would be supported too. It'd just be <playlist> as the root element. It doesn't have to be XML. It could be HTML.

* Some way to associate and load a playlist element from the current document or external playli8st file into the current media element.

If one wants to set up their own way to render and interact with the playlist, they can. Just create the playlist element with JS (or import it from the playlist file) and work with it there instead of appending it to the body or specifying it via markup.

So, yes, the playlist element should be rendered (width and height styles honored) by the browser and the browser should do all the setup of interaction so the playlist looks, feels and works like a foobar/winamp playlist.

The use-case for doing this is to make it way, way easier and less annoying to deal with playlists.

* Loop, shuffle, random, sorting (different ways, including randomize) and repositioning of tracks functions should be supported too (or at least have a way that you can specify a function to call when the use requests one of those)

The xspf format is also kind of overkill, so it's probably best to just make something simple.

Don't think nesting of playlists is needed.

<track> is already used for other things.

I've been wondering how to best do playlists in HTML5. It's actually less about supporting a specific playlist file format, but more about how to queue up the next audio/video file for an <audio> or <video> element such that there is gapless playback. This includes pre-buffering the next file and being able to do cross-fades.

So, maybe what we need is a JS object "Playlist" that maintains a queue of audio or video files that will be played back in an existing audio or video element, a way to reorder them, a way to transition between them.

(Gapless playback is bug 7253, this bug is about anything we need beyond that.)

It seems that a new element is not absolutely necessary. I wonder if  a defined rel value on an list element could do the job. Something ala

     ul rel='playlist'

YouTube

<ol 
    id="watch7-playlist-tray" 
    class="yt-uix-scroller" 
    data-scroll-action="yt.www.watch.lists.loadThumbnails" 
    data-scroller-offset="563" 
    data-scroller-mousewheel-listener="" 
    data-scroller-scroll-listener="">
    <li 
        class="video-list-item yt-uix-scroller-scroll-unit " 
        data-video-id="LsZEv7kAllo" 
        data-video-clip-end="None" 
        data-video-title="Verdi: Requiem" 
        data-index="1" 
        data-video-clip-start="None" 
        data-video-username="UCtelevision">
    <li…

See for example:
https://www.youtube.com/watch?v=bFCxJ56n3zY&playnext=1&list=PL490F5639C2CA0672&feature=results_main

(In reply to comment #7)
> (Gapless playback is bug 7253, this bug is about anything we need beyond
> that.)

I suggest to resolve that first then, because it will solve the fundamental requirements of playlists.

In case you're after a use case, here's an example: implementat a radio station as a Web app which needs to queue up a music playlist for playback using the <audio> element and provide transition effects (fade over). Or a DJ app. Or something like iTunes. You only ever really want one <audio> element  (or at most two) on the page to feed new music urls to.

(In reply to comment #6)
> <track> is already used for other things.

Ah, yes. Understood.

I'm closing this because I don't think that a high-level declarative feature is appropriate for this. Achieving gapless playback between two media elements is the technical difficulty, tracked by bug 7253.