<embed> should support loading random HTML documents, like <object>

[bzbarsky]

Long story short, everyone except Gecko seems to support this:

<embed src="something.html">

(even without the .html extension) already, even though that doesn't follow the current HTML spec. @qdot is adding support in Gecko because of people who are changing their YouTube embeds from Flash to HTML video by just changing the URL and hence loading HTML in <embed>. The spec should just be updated to acknowledge this reality.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1237963 for a slightly more rambly discussion with concrete examples of YouTube embeds.

[Ritsyy]

I would like to work on it, as in the embed element specifying where it is written for "typically non HTML" content or any suggestion for particular changes that should be done?

[bzbarsky]

The processing model for <embed> just needs to look a lot more like that for <object>. Right now the former just talks about SVG and plug-ins; it needs to handle all content types like the latter does.

[Ritsyy]

@bzbarsky yes got your point. Working on it

[domenic]

Fascinating, Chrome at least treats text/asdf as text/html, whereas it treats application/asdf as "unsupported plugin". (Related to #3876)

• https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6092
• https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=6093

[bzbarsky]

Fascinating, Chrome at least treats text/asdf as text/html

That's a value of the "type" attribute, or an HTTP header value?

What Firefox is implementing here is that if the <embed> has a type attribute and the type is not something the browser knows to be a document, image, etc type (defined below), then we either use a plug-in (basically only for Flash) or don't do the load at all. If there is no type attribute, we do the load, examine the server-returned type, and then act just like <object> would for that type.

The determination of whether it's a type we know about is identical to the one that <object> uses to decide whether to render as an image or a document or what, and goes like so:

1. Check a whitelist of image MIME types. I can produce that list if desired.
2. If the built-in PDF viewer is enabled, we know about "application/pdf".
3. Something about video types that is not clear to me (in particular, we render them as documents just like when loaded in an <iframe>, I think?).
4. A whitelist of document types (text/html, text/plain, etc, etc; I can produce the list as needed).

Again, the basic determination is the same one that <object> already does, so we could spec it to share that determination if we adopt this approach...

[domenic]

Hmm, that's very different from the current spec's architecture; in particular the current spec always does the request (if a src="" attribute is present).

Not sure how much work to bite off here; I'm coming from #3876 which looked like a really small change (see #3900 / https://whatpr.org/html/3900/iframe-embed-object.html#the-embed-element-setup-steps for my current draft). I was hoping we could just expand the image/svg+xml case.

[bzbarsky]

in particular the current spec always does the request (if a src="" attribute is present)

Yes, this is what Firefox was doing until recently. We changed just a bit ago due to some issues with that setup. We could keep doing the request, but we wouldn't want to actually render it....

[bzbarsky]

Right, so #3876 aims to describe the rendering observables, I think. And we basically went with "don't fetch if we know we won't render it". At least I am pretty sure we did. @qdot would know for sure.

[qdot]

Yup, that's what I did. Now we just render nothing though, where it sounds like we should at least show a "Unsupported Format" box.