W3C home > Mailing lists > Public > www-html@w3.org > October 2008

Re: HTML IMG tag.

From: Elliott Sprehn <esprehn@gmail.com>
Date: Fri, 10 Oct 2008 15:32:40 -0400
Message-ID: <f9a5c32c0810101232g3382fc5fm5c5d39346d646c54@mail.gmail.com>
To: "João Miguel Lopes Moreira" <multi.jmlm_1970@hotmail.com>
Cc: www-html@w3c.org
On Fri, Oct 10, 2008 at 11:37 AM, João Miguel Lopes Moreira
> Instead of having only HTML:
> IMG SRC="data:image/gif;base64,ZXYetc..."
> Having also HTML:
> IMG SRC="data:.gif;base64,ZXYetc..."

File extensions are really meaningless in the context of the web. The
MIME type is the standardized way to determine the format of a file.

File extensions may also be mapped to entirely different formats on
different machines or on the same machine, or the machine might not
even use file extensions. For instance .m files are used by both
Objective-C for implementation files, and by MatLab for code files,
and probably by other things as well.

Many websites deliver HTML, images, scripts or CSS without a file
extension, and nothing prevents you from mapping .awesome to image/gif
on your server.

So using the extension in the <img> tag wouldn't make sense at all
since the extension is really meaningless. What's important to the
browser is the mime type. In the event you load a file from disk it's
up to the operating system (and the UA running on it) to determine the
type of file.

<img src="file:///foo.awesome" title="actually a GIF">

The browser should, using the OS facilities, figure out what kind of
file this is. If the OS depends on file extension then of course this
might not load correctly, however maybe it uses some kind of file
metadata (like classic Mac OS, and somewhat OS X), or it uses the *nix
"file" command to do an analysis. The behavior, though, is totally
platform specific.

It should be noted that the IETF specified the standard for Data URIs
(which is what you're talking about), so it's not like the W3 could
change what you want anyway.


- Elliott
Received on Friday, 10 October 2008 19:33:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:21 UTC