Transition back to nested source elements

See thread in #5 for more information.

As @mikkoh points out, <video> is a good parallel with <model-viewer>, and the precedent set on that tag is to allow a set of nested <source> tags (with optional specification of mime types). Being in line with that allow us to avoid some overly specific names (like our current ios-src), support additional types easily in the future, and be inline with other tags.

Specifically, I believe we should:

• Support nested <source> elements, with required src and optional type attributes
• Remove the ios-src attribute (or deprecate it, moving towards a future removal)
• Leave the src attribute as an easy fallback (this is in line with other elements)

[mikkoh]

I’m cool using <source> if everyone else is 😂

[cdata]

Excellent question @mrdoob . From the embedded content section of the HTML5 spec:

There are three ways to specify a media resource, the srcObject IDL attribute, the src content attribute, and source elements. The IDL attribute takes priority, followed by the content attribute, followed by the elements.

From the sounds of things, the attribute always takes precedence. Another interesting tidbit is this:

If a src attribute of a media element is set or changed, the user agent must invoke the media element’s media element load algorithm. (Removing the src attribute does not do this, even if there are source elements present.)

This suggests two important things:

1. No matter what, if src is set to null (e.g., the attribute is removed), nothing should be loaded
2. <source> element URLs should not be considered fallbacks when the src attribute is removed / set to null

From elsewhere in the spec, it also has this to say about <source> elements:

Dynamically modifying a source element and its attribute when the element is already inserted in a video or audio element will have no effect. To change what is playing, just use the src attribute on the media element directly… Generally, manipulating source elements manually after the document has been parsed is an unnecessarily complicated approach.

This is a very helpful simplification of the problem. Otherwise, we would have to create a MutationObserver just to know when the src attribute on the <source> elements has changed in a meaningful way.