17

Inspired by this question, where the poster casually states as fact that <object> should be used instead of <img> to embed images in HTML documents.

I'm developing a web app at the moment, and, being a perfectionist, I try to make it all shiny and compliant with all the standards. As far as I know, the <img> tag is to be deprecated in the upcoming standards for xHTML, and as nowadays even IE is able to handle <object> properly, I wanted to use the <object> tag for all the images on my site

It became clear that the "upcoming standards" the poster was talking about was the abandoned XHTML2 spec, which didn't even formally deprecate <img> anyway. (Although there were apparently rumors to that effect.)

To the best of my knowledge, I've not seen anyone in the web development community advocating for the usage of the general-purpose <object> tag over the arguably more semantic and definitely more compatible <img> tag.

Is there a good reason to use <object> instead of <img>? Should <object> even be used at all in place of <img> – what might this break?

Community
  • 1
  • 1
josh3736
  • 139,160
  • 33
  • 216
  • 263

5 Answers5

18

To answer the question in the heading: yes, it is valid, of course. The validity of an object element does not even depend on the type of data being embedded. If you meant to ask whether it is correct, then the answer is yes, there is nothing in the specifications that would forbid it or recommend against it.

Among the possible reasons for using object to embed an image, the most practical is that it allows the fallback content to contain HTML markup, such as headings, lists, tables, and phrase markup. The img element lets you specify only plain text as fallback content—even paragraph breaks cannot be specified.

For accessibility reasons, any image should have fallback content to be rendered e.g. when the document is used in nonvisual browsing (screen reader, Braille, etc.) or the image is not displayed for one reason or other. For any content-rich image (say, an organization chart, or a drawing describing a complex process), the fallback content needs to be long and needs to have some structure.

However, it is rare to use object for embedding an image. The importance of fallback content is not widely understood, and practical economical and technical considerations often cause fallback issues to be ignored. Moreover, object has a long history of slow, buggy, and qualitatively poor implementation in browsers. Only recently has it become viable to use object fairly safely for image inclusion.

The question which element is more semantic is mostly futile, and answers typically reflect just various ways to misunderstand the concept “semantic.” Both img and object mean inclusion (embedding) of external content. The img element is in principle for the inclusion of images, whatever that means, though it has also been used to include videos. For the object element, the type attribute can be used to specify the type of embedded content, down to specific image type, e.g. type=image/gif, or it may be left open.

This implies that the object element is more flexible: you can leave the type unspecified, letting it to be specified in HTTP headers. This way, the type of the embedded data could be changed without changing the object element or the embedding document in general; e.g., you could start with a simple version where the embedded content is an image, later replaced it by an HTML document (containing an image and text for example).

Jukka K. Korpela
  • 195,524
  • 37
  • 270
  • 390
9

The only time I've ever seen an object used to show an image is to create a "fallback" when the intended object couldn't be loaded for whatever reason. Take this example from the W3 specs:

<OBJECT title="The Earth as seen from space" classid="http://www.observer.mars/TheEarth.py">
    <!-- Else, try the MPEG video -->
    <OBJECT data="TheEarth.mpeg" type="application/mpeg">
        <!-- Else, try the GIF image -->
        <OBJECT data="TheEarth.gif" type="image/gif">
            <!-- Else render the text -->
            The <STRONG>Earth</STRONG> as seen from space.
        </OBJECT>
    </OBJECT>
</OBJECT>

Only ever attempting to load an image via an object is basically removing the semantic meaning off of the image, which I would consider very bad practice.

animuson
  • 53,861
  • 28
  • 137
  • 147
5

There is no good practical reason to use object instead of img. object has always been inconsistently and messily supported. Use img for images, embed for flash content, and video or audio for multimedia content. Basically the only use of object left is for invoking specific plugins.

That said, the philosophical position for object's existence is still very good. It was meant to be a generic element for any type of content which can contain nested fallback content. W3C/XHTML2 had a very idealistic roadmap for html which emphasized syntactic and semantic purity and wanted to do things like allow href on any element (eliminating a), and eliminate img in favor of object. However, browsers could never seem to get object right in a fully generic way. Additionally, it was difficult to define the js APIs for a generic object element. That's a big reason why video and audio are separate--object serving a video won't expose the js video APIs.

However, XHTML2 lost and HTML5 won and HTML5 favors img, so use img.

Francis Avila
  • 31,233
  • 6
  • 58
  • 96
  • I assume you meant XHTML2 lost? Also, isn't XHTML2's philosophy of favoring a generic `` element in direct opposition of semantic purity? `` means nothing; `` means it's an image. – josh3736 May 02 '12 at 03:38
  • Typo--xhtml2 lost. `object` types were supposed to be discerned by the `type` attribute. Semantically they were trying to unify the various inconsistent methods of embedding content. So `object` subsumes `iframe`, `embed`, `applet`, `img`, etc. They did not see mime type as semantically significant. This is consistent with html's resource-representation distinction, where the same url could potentially respond with an image or a video (in any number of different formats) depending on content-type negotiation. I think this way of thinking ended up being way too pure to be practical. – Francis Avila May 02 '12 at 03:49
  • XHTML2 didn't eliminate `img` in favour of `object`. The `img` element was in XHTML2 right until the end. But XHTML2 allowed the `src` attribute on any element, which would make it act like an `img` element, so the `img` element was largely unnecessary in XHTML2. – Alohci May 02 '12 at 07:18
0

I came across a real-world use case for using object over img tags. I’m using PlantUML to generate SVGs that include tooltips. If I use the img tag to include the img, none of the native SVG pointer events events work. But if I use the object tag, presto - all over the onhover/mouseover behaviors work as expected.

Carlo Quinonez
  • 164
  • 1
  • 6
0

I've just experienced a problem which forced me to use <object> instead of <img>.

I have a file named lv2x.php, and I used it as a svg file (php headers "Content-Type: image/svg+xml"). Inside the svg file, I imported a google font CSS link (used link-href or @import).

The problem is that: when I open the file in a new tab: https://.../lv2x.php?lv=10 it displays the font I used for a text correctly. But when i use <img src="https://.../lv2x.php?lv=10">, it falls back to default font.

No matter how much I tried to find a solution, searching on Google, asking ChatGPT,... the font of the svg file keeps being wrong. The solution I found is that using <object type="image/svg+xml" data="https://.../lv2x.php?lv=10">. The font displays correctly again.

Vidar S. Ramdal
  • 1,164
  • 1
  • 14
  • 38
  • Actually, you can use custom fonts in `` tags, but you need to include a `@font-face` rule with an embedded data URL for the fontfile src. Since SVGs in `` tags need to be self-contained. See also ["Cross-browser embedded font in svg image"](https://stackoverflow.com/questions/20905026/cross-browser-embedded-font-in-svg-image) – herrstrietzel May 09 '23 at 17:06
  • Thanks for your answer. As mentioned in the article you linked here. It seems to be working when we need to encode the whole font as base64 inside the svg file, which seems not to be good for my case. The `lv` parameter displays a number in the image, which means everytime I use another value for `lv`, it will cache the whole file including the font embedded as base64 inside them. I think it's not a good choice to cache the font data for 100 times instead of once. – noudavinci May 11 '23 at 18:39