Clarify how to handle using sub resource web bundles when browsers support it, and traditional bundlers when they dont

[SinZ163]

Title is a bit verbose but gets the point across.

With script tags, when module support was added, nomodule was also added so you could have both in your markup and the browsers that knew modules loaded modules and intentionally didn't load nomodules, I feel a similar pattern is needed for WebBundles.

In the chromium Origin Trial, it is mentioned that its possible in JS to do feature detection for this, but that would require having web app developers to effectively polyfill webbundles ourselves and only add the JS bundle script tag at runtime once feature detection has happened, increasing the size of the html body and adding latency when instead this feature can ship with polyfill mechanisms baked in.

[horo-t]

Introducing <script nowebbundle type=text/javascript src=bundle.js></script> could be a solution for this.

Currently we are using link elements for subresource web bundles in the Origin Trial.
But there is a discussion to use <script> elements for security reason.
So if we introduce<script type=webbundle> elements instead of <link rel=webbundle>, introducing <script nowebbundle> sounds plausible.

[horo-t]

CC: @littledan

[hayatoito]

We don't have any special support for an unsupported environment yet. So I guess a workaround would be a general one, such as:

<script>
if (!feature_detection()) {
  const script = document.createElement('script') ;
  script.src = ".../traditional-bundle-runtime.js";
  document.body.appendChild(script);
  ...
}
</script>

This might add latency, as you mentioned.