Remove <source> configuration API

It’s pedantically correct but potential confusing - including requiring users to know/specify mime-types).

Instead, use a simpler, attribute-based approach. The main glTF resource can remain source, and we can have other optional attributes for source-usdz and potentially source-ml (or source-fbx).

[mikkoh]

Sorry to bring this up way late in the game.

I would argue that you could infer the model type by the file extension if type is not provided. type should be optional.

<model-viewer> has some parallels to <video>. For example it displays content from multiple sources.

eg for video

<video>
    <source src="some.webm" type="video/webm" />
    <source src="some.mp4" type="video/mp4" />
    This browser does not support the HTML5 video element.
</video>

<model-viewer> could look like this:

<model-viewer>
    <source src="some.usdz" />
    <source src="some.glb" />
    All kinds of bad things happened and we can't do a thing
</model-viewer>

Also the naming of src and ios-src precludes some level of importance src is more important than the secondary ios-src. Also if USDZ is supported in the future by THREE natively do we still want to call it ios-src.

Doing this would allow for the follow:

1. Handle an ever increasing number of potential sources that could be rendered
2. Is inline with how <video> and <picture> work
3. There’s no need to remember arbitrary attribute names eg src, ios-src, hologram-src??

[donmccurdy]

A couple notes:

1. .glb is the most efficient glTF packing option in nearly all cases - I don’t think you’d ever need both a .gltf and .glb to be specified.
2. .drc is a geometry-only Draco file, unrelated to glTF, and it’s not widely used. glTF files using Draco compression still use the normal .glb or .gltf extensions. If a client doesn’t support Draco, we’d need some other indicator.

In general I don’t think <model-viewer/> can or should try to support very many formats – this gives users the impression that the format doesn’t matter, and that they should bring whatever they have and we’ll deal with it. Unfortunately many common formats (COLLADA, FBX, OBJ) are very inefficient for use on the web, and/or unreliable to parse, and IMO we’re setting our users up for a bad experience by heading in the direction of an ever increasing number of sources.

Nevertheless, the suggestion of src instead of *-src seems fine to me.