Consider to reorder 'source' tags that based on browser support and compression benefits

[JulienWilhelm]

Hi,

In some page talking about source element, like:

• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video (good approach?)
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio (bad approach?)
• https://developer.mozilla.org/en-US/docs/Web/Guide/Audio_and_video_delivery (bad approach?)

It is explained that the browser will choose the first format he knows.

But in all examples, the source tag is used by starting from most well supported format to the least one:

• Source MP3 before source OGG
• Source MP4 before source WebM

Why do not consider to reorder that based on browser support and compression benefits?
That would seem more logical.

[Rumyra]

Thanks for the question @AwebsomeFr

So the way it is described in the docs is correct - say a browser supports mp4 but not webm - it will skip over the webm file and carry on to mp4, using that file.

If you believe this shouldn't be the case, the place to raise an issue would be against the spec itself (ie not MDN) :)

[JulienWilhelm]

Thanks for your response @Rumyra.

It seems that I was too fast.
The first link I mentioned seems to follow the logic of the spec, but the others don't.

Here what I read on https://developer.mozilla.org/en-US/docs/Web/Guide/Audio_and_video_delivery

<video
  controls
  width="640"
  height="480"
  poster="initialimage.png"
  autoplay
  muted>
  <source src="videofile.mp4" type="video/mp4" />

  <!-- fallback for browsers that don't support mp4 -->
  <source src="videofile.webm" type="video/webm" />

  <!-- specifying subtitle files -->
  <track src="subtitles_en.vtt" kind="subtitles" srclang="en" label="English" />
  <track
    src="subtitles_no.vtt"
    kind="subtitles"
    srclang="no"
    label="Norwegian" />

  <!-- fallback for browsers that don't support video tag -->
  <a href="videofile.mp4">download video</a>
</video>

So MP4 (best support) is always loaded before WebM (worst support, better compression)?

And in https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video

<video controls width="250">
    <source src="/media/cc0-videos/flower.webm"
            type="video/webm">
    <source src="/media/cc0-videos/flower.mp4"
            type="video/mp4">
    Download the
    <a href="/media/cc0-videos/flower.webm">WEBM</a>
    or
    <a href="/media/cc0-videos/flower.mp4">MP4</a>
    video.
</video>

Between the first link and the next two I've mentionned, there are to 2 different approaches.

Am I right? (I hope so!)

[wbamberg]

Just to check my understanding: you are saying that:

• because the browser will try the sources in order and load the first one it can
• then you should order your sources by which one you want to use (e.g. because it compresses better, or...)

...so our examples should list the "better" option first. So in a case like https://developer.mozilla.org/en-US/docs/Web/Guide/Audio_and_video_delivery#html_video, if webm is preferable to than mp4, then we should have a different order given in the example?

If so that sounds convincing to me. We could make this guidance explicit in places like https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video#usage_notes.

[Rumyra]

Thanks for the reply @AwebsomeFr - I believe then yes the first example you provided should have webm & mp4 swapped - if I've understood correctly :)

[JulienWilhelm]

@wbamberg Exactly.

WebM (video) & OGG (audio) = lower support, but better compression.
MP4 (video) & MP3 (audio) = better support, but lower compression.

So, these examples should give a try to the least supported format first (WebM before MP4, OGG before MP3):

1. To reduce data consumption (eco and perf friendly).
2. Because it sounds logical (fallbacks will never or rarely used else; is there a browser that support OGG but not MP3, or WebM but not MP4?)