Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
zcorpan opened this issue May 3, 2019 · 8 comments
Open

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

zcorpan opened this issue May 3, 2019 · 8 comments
Labels

Comments

@zcorpan
Copy link
Member

zcorpan commented May 3, 2019

See #4590

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

also #3752 (comment)

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.

@zcorpan zcorpan added clarification Standard could be clearer topic: embed and object labels May 3, 2019
@briansmith
Copy link

(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
Copy link
Member Author

zcorpan commented May 13, 2019

Is object different than img wrt sizing?

@annevk
Copy link
Member

annevk commented May 14, 2019

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 domenic added the agenda+ To be discussed at a triage meeting label Mar 23, 2022
@domenic
Copy link
Member

domenic commented Mar 23, 2022

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
Copy link
Member Author

zcorpan commented Mar 24, 2022

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
Copy link

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

@domenic
Copy link
Member

domenic commented Jun 16, 2022

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.

#7939 is appealing, if we could just remove that capability...

@annevk
Copy link
Member

annevk commented Jun 16, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

5 participants