22458 2013-06-25 16:43:33 +0000 Change the spec to allow rendering of captions for audio when controls are visible 2013-06-26 13:26:54 +0000 1 1 1 Unclassified TextTracks CG WebVTT unspecified All All RESOLVED WORKSFORME https://bugzilla.mozilla.org/attachment.cgi?id=767116 P2 normal --- 1 mardeg silviapfeiffer1 giles mike public-texttracks dave.null oldest_to_newest 89822 0 mardeg 2013-06-25 16:43:33 +0000 According to Ralph Giles at https://bugzilla.mozilla.org/show_bug.cgi?id=886748#c3 if there's ui displayed, which is conditional on 'controls' then aborting in step 1 at http://dev.w3.org/html5/webvtt/#dfn-rules-for-updating-the-display-of-webvtt-text-tracks based solely on the element being <audio>, ie. without checking for the existence of a rendering area which *does* exist when there is a 'controls' boolean attribute, is wrong. Please change the text of that rule to allow vendors to render captions for <audio> elements that have a rendering area. 89827 1 giles 2013-06-25 17:49:41 +0000 I'd state it a little more generally. Step 1 assumes <audio> has no rendering area. Does that make sense? <audio controls> has a built-in ui elements which render. It could make sense that <audio><track default></audio> also has a rendering area in which to do caption display. Mardeg, can you explain the use-cases you're trying to address with this, and why e.g. using <video> instead isn't sufficient? 89835 2 mardeg 2013-06-25 18:53:16 +0000 (In reply to comment #1) > Mardeg, can you explain the use-cases you're trying to address with this, When people only record audio of their presentations, and want to use CSS animations/transitions for the image slideshows and/or other javascriptless animations like SMIL in SVG without any video, having the captions for hearing impaired would be ideal. > and why e.g. using <video> instead isn't sufficient? I haven't tested that workaround enough to know the answer to that. Right now I can only speculate that some future curated authoring/hosting sites allow <audio> but not <video>. The key is being able to do it without relying on javascript for when the user isn't in control of settings such as at a kiosk that has javascript off. 89867 3 silviapfeiffer1 2013-06-26 03:27:02 +0000 You can render captions for audio resources by putting them into a <video> element. The controls are not regarded as a rendering area for the audio - audio is only rendered to the audio device. An <audio> element is not rendered visually unless it has controls, so there is no place to render subtitles into - in particular if you are creating your own controls. Using the <video> element works perfectly fine. You can control the size of the rendering area through CSS. Also, I don't see why sites should disallow the use of <video> when they want to render captions on audio resources. 89874 4 mardeg 2013-06-26 08:26:44 +0000 (In reply to comment #3) > Also, I don't see why sites should disallow the use of <video> when they > want to render captions on audio resources. I was thinking along the lines of soundcloud-like sites that are audio-specific, where people couldn't be trusted to only upload audio to (presuming that playing a video .ogg in <audio> won't show the video), but in any case this is resolved and now it's on the record for people looking it up in future. 89886 5 silviapfeiffer1 2013-06-26 13:26:54 +0000 It's even explained in a note in the HTML spec. See the first note in http://www.whatwg.org/specs/web-apps/current-work/#the-audio-element . I don't know what else we can do to explain this to people though.