Bugzilla – Bug 20890
Poster attribute for audio element to be used with subtitles in track element
Last modified: 2013-02-09 02:26:12 UTC
As the track element may be used inside an audio element and as the track element can be used to provide subtitles, it would be great to have a poster attribute in the audio element, so, the image linked in the poster attribute would be display as background image in the "screen" (box) where the subtitles are displayed.
Thanks for your interest on that topic.
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
Change Description: none
The audio element has no rendering region - it does not display anything. In fact, it does not display captions or subtitles either. If you have a audio file and want to display subtitles by using <track> you have to put the audio file into @src of a <video> element. Then what you describe should be exactly what happens.
Ok, this is logical if an audio have some subtitles (that are visual), it becomes audio-visual, so, it's some video. So, I completely agree (and technicaly, it looks like it's not a problem to put an audio file in the src attribute of a video element.
Now, the point is that it is permited to have a track element with the kind attributes set to "subtitles" in an audio element, so, it should not be permited as it leads to something not logical.
So, I think this should be redefined as another bug.
I've added bug 20903.
(In reply to comment #2)
> Now, the point is that it is permited to have a track element with the kind
> attributes set to "subtitles" in an audio element, so, it should not be
> permited as it leads to something not logical.
> So, I think this should be redefined as another bug.
I'm replying in the other bug.