Re: [whatwg/fetch] Split 'document' destination into 'frame' and 'iframe'. (#948)

> it might be reasonable to make embed and object work more like strangely-spelled iframe elements?

They have quite different layout behavior in the image case, no?  Including in Chrome.

> If Firefox is okay with moving slowly towards making embed/object always create browsing contexts as well (even if it's only visible once the load event fires)

What web-observables would this actually affect?

Ignoring for the moment plug-ins (let's pretend we killed them already), there are basically two cases for embed/object in the spec and in Gecko's implementation right now: document and image.  Which case we're in is decided based on the MIME type of the last load triggered via the "src"/"data" attribute respectively.

If you set the relevant attr to a URL that returns a non-image MIME type that the browser is able to render, you get a browsing context (once we get the headers from the server) and general iframe-like layout behavior.  The resulting browsing context can be navigated via its `Location`, including to image URLs (which will render like they would in an iframe).  But setting the relevant attr again will (always? I'd have to check the code) get rid of the browsing context and then run the selection logic again once the response is received.

If you set the relevant attr to a URL that returns an image MIME type, we don't create a browsing context at all.  We just have the image data (like `<img>` does), and create a layout object identical to the one for `<img>`, which knows how to do the right intrinsic sizing, etc.  This _could_ perhaps be done on top of a browsing context but would require some work to make the layout behavior correct.  This is work that Chrome is apparently already doing, or it's doing _something_ at least.  If I do `<object data="100x100px-image" style="height: 200px"> in Chrome, I get a 200x2000 image shown, which is totally not how iframes work.  Also, note that the renderings of an iframe pointing to an image are NOT interoperable across Chrome and Firefox, nor are they standardized, unlike the case of `<object>` pointing to an image.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/pull/948#issuecomment-545041366