Add <nomodel> for graceful fallback of content in legacy browsers

[colinbendell]

As a front end developer, I need to provide an equivalent experience for legacy and long tail browsers without having to resort to more javascript. This is particularly true for commerce product views. To simplify the feature detection, the model should provide an optional <nomodel> element which could contain traditional <video> or <img> markup.

<model>
  <source ...> 
  <nomodel>
    <img src="animated-version.mp4">
  </nomodel>
</model>

This will allow for legacy browsers to skip the unknown markup gracefully and instead use the fallback placeholders. It would also allow a mobile device under battery or network duress to attempt to render something less intensive.

[beaufortfrancois]

It seems like <model> may want to follow <picture> HTML element pattern and have the last children as a fallback.

<model>
  <source src="assets/example.usdz" type="model/vnd.usd+zip">
  <video src="animated-version.webm"/>
  <img src="animated-version.gif"/>
</model>

[colinbendell]

@beaufortfrancois this could make sense, so long as a full <picture> element could be used. This is particularly useful because <picture><source> support media and type scoping. So it could look like:

<model>
  <source src="assets/example.usdz" type="model/vnd.usd+zip">
  <picture>
    <source src="animated-version.mp4" type="video/mp4">    
    <source src="animated-version.webp" type="image/webp">    
    <img src="animated-version.gif"/>
  </picture>
</model>

[othermaciej]

Overall, the request to have fallback content makes sense.

As far as specific ways to do this, I think this suggestion is along the right lines:

It seems like may want to follow HTML element pattern and have the last children as a fallback.

But IMO it should be any children other than <source> children as the fallback rather than specifically the last child. That way fallback could be multiple elements without having to add a gratuitous div around them.

[spartanatreyu]

Should the fallback content be limited to replaced elements or should they allow anything?

Should a <p> inside a <model> element be treated as fallback content? What about a <script>? Does the <script> only execute when the model can't be loaded?

[grorg]

I agree on the fallback. I think it should be limited to replaced elements though. Unfortunately that means that you can't do multiple elements, but avoids @spartanatreyu's point about script.

[grorg]

Hopefully that commit addresses the issue. Please speak up if not!

[colinbendell]

@grorg - a few comments/questions:

1. you specify that the last element will be used as fallback. Does this mean that in the following example, the <video> would be picked up and used and the <picture> tag would be ignored? Is that correct? Is there any prior art that uses this heuristic?

   <model>
   <source src="fake.typ1" type="imaginary/type-1">
   <source src="fake.typ2" type="imaginary/type-2">
   <picture>
       <source src="animated-version.webp" type="image/webp">
       <img src="animated-version.gif"/>
   </picture>
   <video>
   <source src="video-version.mp4" type="video/mp4">
   </video>
   </model>

2. Fallback appears to be an under spec'd aspect for most replacement elements. (Fallback is only framed in terms of unsupported element, but not about the fallback UX). That said, I would love to see some language that gives the UA some optionality when selecting the source or chosing to fallback. This would allow the UA to consider environmental situations such as battery, network, or lighting and decide to fallback to a safer alternative. This would be a break in tradition where <picture> only falls back to <img>, <video> and <audio> will leave an empty player. (But would provide a superior user experience)

3. There will be some preloader considerations as well that will need to be defined.

4. What would the currentSrc return when a fallback is selected? (is null sufficient?)