[Bug 13333] audio, video (and source) elements require param children or equivalent

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

--- Comment #48 from Glenn Adams <glenn@skynav.com> 2011-08-03 13:58:45 UTC ---
(In reply to comment #47)
> (In reply to comment #36)
> > (In reply to comment #33)
> > > In any case, I agree with Henry that we should neither destroy the parsing of
> > > <source>
> > 
> > 'destroy parsing'? what are you talking about?
> 
> Deployed content uses <source> like this:
> 
> <video>
>   <source src="video.mp4">
>   <source src="video.webm">
> </video>
> 
> The resource selection algorithm only considers child source element of
> <video>. If a browser changed the parsing of <source> to not be a void element,
> the above would be equivalent to:
> 
> <video>
>   <source src="video.mp4">
>     <source src="video.webm"></source>
>   </source>
> </video>
> 
> The second <source> element would not be considered and existing content would
> just not work. Changing the resource selection algorithm to consider *any*
> descendant <source> element would not be a good idea, as it precludes ever
> making spec changes like putting extra <audio> tracks inside <video>.

It is not the intent of this bug report to propose nested source elements, but
only to enable param as a child of video, audio, and source. So, in this sense,
the HTML specific syntax processing would need to reclassify source from void
to normal element type. A missing end tag for source can be implied by the
following rule (to be added 8.1.2.4 Optional Tags:

"A source element's end tag may be omitted if the source element is immediately
followed by another source element, or if there is no more content in the
parent element."

At present, video and audio do not allow optional end tags in the HTML syntax,
so end tag implication does not apply there. Also, end tag implication does not
arise in the XHTML syntax of HTML5.

While the proposed change would entail a modification for HTML syntax parsing
to handle source end tag implication, that should be a trivial change in the
current experimental implementations of HTML5.

Finally, I would note that it may be acceptable to add param only to video and
audio, and not require its support with param. As I noted in the original
comments to this bug, adding param to source is a secondary, convenience
mechanism that permits separating those parameters that are independent of the
selected source from those parameters dependent on the selected source.
Although it would be less general, not having param on source could still be
accommodated through other conventions, e.g.,

Example #3 - Configure DLNA A/V Connection Manager for Audio Playback with RTP
preference over HTTP

<audio>
  <param name="source-1-dlna-res-protocol"
value="rtsp-rtp-udp:*:audio/mpeg:*"/>
  <param name="source-2-dlna-res-protocol"
value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3"/>
  <source src="audio.mp3">
  <source src="audio.mp3">
</audio>

However, this is clearly a more awkward way to address source dependent
parameters than expressing such parameters as children param elements on
source.

Regards,
Glenn

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 3 August 2011 13:58:48 UTC