>

Question

I am writing an introductory HTML course. I remember discovering 9 years ago as I was learning HTML that both and worked

Answer 1

Indeed. Modern browsers will display code that is not valid in order to make sure that old websites still display correctly and slightly-invalid code doesn't screw up a page.

For example, forgetting to close a <tr> before you open a new one - all modern browsers will simply assume you closed it.

I'm not aware of a well-used, up-to-date browser that will fail to display an <image> tag, but will display an <img> tag.

Answer 2

They have different usages in SVGs. The image tag creates a specific element in an SVG and can not be replaced by the img tag.

Fiddle Example

Answer 3

Yes and no. As you point out <image> has been a synonym for <img> for a long time. I believe it was an early Netscape browser that first did this, possibly to compensate for user error, or possibly because there was dispute at the time whether the element should actually be called <image> or <img>.

Anyway, as pst points out, once it was implemented in a browser that dominated the market of the time, web pages came to rely on it. Its persistence is then down to commercial pressure on the browser manufacturers. If all the major browsers support it, then Browser A decides that although it supported it in Version V, it won't support it in version V+1, as soon as version V+1 is released, they get lots of messages saying "Site S is broken in your latest browser. You browser is rubbish. I'm going to switch to browser B".

The HTML5 parsing spec requires that the <image> tag is mapped to the img element at the tree construction stage, so there can never be any justification for using it.

I would be less concerned about browsers, than other HTML consumers, such as the lesser known search engines. I believe that the image for img synonym is not widely known, and the many such tools would therefore fail to pick up <image> as referencing an image resource.

Answer 4

I just finished debugging this problem, which I was committing, having not previously read the above answers.

While not full-blown browsers, an email client is often used as if it were a browser.

I discovered, the hard way, that the Android Gmail client, using naked HTML (with a default naked DTD specification), does exhibit this problem. It only responds to <img /> [i.e., not <image />]. gmail.com is fine with <image />, but not the Android gmail client.

While an email client isn't really a browser, I thought you might be interested anyway.