Transition back to nested source elements

[smalls]

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)

[cdata]

Just want to note that a lot of good discussion on this topic is taking place in the previously closed issue #5

[mikkoh]

FYI. I was working on this last night. Hopefully have something finished in the next two days.

Because I'm unfamiliar with the deprecation cycle for <model-viewer> what I've done is made it so that <model-viewer> prefers <source> to determine URLs to models but falls back to the src and ios-src.

[smalls]

See #452 for a sample of how we've renamed an attribute - although, that being said, the change to <source> feels a bit more fundamental so I appreciate the fallback. I'll add an issue to discuss (and then document) the deprecation cycle - see #473.

[mrdoob]

Because I'm unfamiliar with the deprecation cycle for <model-viewer> what I've done is made it so that <model-viewer> prefers <source> to determine URLs to models but falls back to the src and ios-src.

Does <video> prefer <source> over src?

[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.

[mikkoh]

I don't think we can do:

<model-viewer>
  <source>
</model-viewer>

It's not valid HTML.

It would need to be something like:

<model-viewer>
  <model-viewer-source>
</model-viewer>

[cdata]

@mikkoh what aspect of it being not valid are you most concerned about?

Personally I would like us to strive for enabling content authors to write the most valid HTML possible. Here are some of my thoughts on this topic:

There are a lot of cases where child content might make semantic sense for a custom element, but is not explicitly allowed by the HTML spec. You could make a strong case that <model-viewer> is akin to other media elements such as <video> and <audio>, both of which are allowed to have <source> children by virtue of being media elements.

Perhaps more importantly, if you add a <source> tag as a child of <model-viewer>, it will remain in that logical relationship when parsed. The <source> tag won't be booted out, and it won't mysteriously disappear.

It is correct to say that an HTML validator will say that using <source> inside a custom element is invalid. In practice, it is very easy to "break" the rules, even if breaking them has no real consequence. For example, if I run the W3C validator against Shopify's front page I notice that there are many validation errors, but most of them are probably inconsequential enough to be ignored.

[mikkoh]

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

[elalish]

@cdata This looks like a breaking change, yes? As such, should we prioritize it ahead of 1.0?

[cdata]

I think this could be implemented in a transitional way so that it works in lieu of attributes but will use the attributes if available. The <video> element works this way (see my comment above).

In other words: it would not necessarily need to be a breaking change.

[mikkoh]

Another input point for this conversation. I think this thread shows why it's powerful to leverage <source> and some potential features that could be built on top of it:
WebKit/explainers#75

[elalish]

We're not going to do this because it would only serve to make other file formats like USDZ have a more prominent place in our API. <model-viewer> has no intention of supporting formats other than glTF internally - especially since there's no reasonable way to expose their materials and such through a single API as they just don't match. The fact that ios-src looks tacked on is intentional; ideally it is temporary and can be removed if iOS ever supports WebXR or glTF.

Instead, I'm looking at a vaguely similar-looking API which is instead for bringing multiple glTF models into the same scene (think arranging your couch and end tables). I think this will have much more value to our users.

[mikkoh]

@elalish just to be clear are you thinking of using <source> but with extra HTML attributes to denote which source should get picked? I've been exploring something similar re LODs

[elalish]

No, I think that switching sources is easily enough done externally to MV that I don't see much need for a dedicated API so far. I'm looking at using vaguely similar syntax for combining multiple models in a scene instead.

[mikkoh]

Are you thinking that you'd use the camera orbit distance property to determine when to bring and out a model?

[elalish]

Yes, and maybe camera target too.