search

whatwg / html

HTML Standard
https://html.spec.whatwg.org/multipage/
Other
8.04k stars 2.63k forks source link

Recommend iframe/img over embed/object for some content types #4592

Open zcorpan opened 5 years ago

zcorpan commented 5 years ago

See https://github.com/whatwg/html/pull/4590

Also we should probably more directly recommend to use iframe for HTML (and PDF?) and img for images, instead of embed/object.

also https://github.com/whatwg/html/pull/3752#issuecomment-484051560

object and embed are typically treated as legacy at this point and don't get new features that are added to e.g. iframe or img.

embed or object still make sense for Flash and, I suppose, interactive SVG (iframe doesn't change its size to the resource's intrinsic size... yet), but for HTML (and PDF?) the spec should recommend using iframe and for images img. Maybe mention audio and video as well for completeness.

briansmith commented 5 years ago

(iframe doesn't change its size to the resource's intrinsic size... yet)

<object> resizing to the contents of a cross-origin resources is another same-origin-policy violation very much like what caused typesmustmatch to be removed.

I think the recommendation should go much further: NEVER use <object> or <embed>; i.e. mark both as deprecated/historical and recommend using <iframe> for SVG/HTML/PDF, or <img> for SVG.

zcorpan commented 5 years ago

Is object different than img wrt sizing?

annevk commented 5 years ago

Well, object can be img, video (not sure), or iframe, in terms of sizing. And perhaps there's something special for plugins? Other than plugins it shouldn't have more capabilities though.

domenic commented 2 years ago

I would support, and be willing to do spec work for, deprecating object and embed. They are very bad. The less people use them, the more we can work on security improvements such as #7327 and the auto-sizing issue mentioned here, as well as simplifications such as generally unifying them with iframe logic as much as possible.

I think the main question is whether we want to have a carveout to still allow same-origin interactive-SVG <object>, because it has autosizing behavior which is hard to replicate, and if constrained to same-origin, is not a security issue. (The HTML spec itself uses it for that purpose.)

zcorpan commented 2 years ago

Allowing object for interactive SVG for now seems reasonable. If iframe gets an opt-in to autosizing that works for SVG, we can recommend using iframe, but that's not the case right now.

vincentbernat commented 2 years ago

For PDF, an iframe displays a download prompt for browsers not able to do rendering.

domenic commented 2 years ago

So note that both embed and object have autosizing to interactive SVG contents (whereas iframe does not): http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10403 . This makes the choice of what to deprecate a bit arbitrary.

https://github.com/whatwg/html/issues/7939 is appealing, if we could just remove that capability...

annevk commented 2 years ago

If the proposal from @tabatkins and @chrishtr et al. to bring that functionality to iframe elements (via opt-in, but still) goes through, I'd be comfortable recommending people use that instead. Perhaps in the future we can then close that cross-origin policy leak. I don't really think it should keep us from encouraging folks to switch away from embed and object elements.