
Why do we have an IMG element? - gthank
http://diveintomark.org/archives/2009/11/02/why-do-we-have-an-img-element
======
wallflower
Reading the full thread gives me an appreciation for how well some people can
aggressively but politely have a mail thread discussion.

Marc's final diplomatic reply:

"So, we're probably going to go with <IMG SRC="url"> (not ICON, since not all
inlined images can be meaningfully called icons). For the time being, inlined
images won't be explicitly content-type'd; down the road, we plan to support
that (along with the general adaptation of MIME). Actually, the image reading
routines we're currently using figure out the image format on the fly, so the
filename extension won't even be significant."

[http://1997.webhistory.org/www.lists/www-
talk.1993q1/0182.ht...](http://1997.webhistory.org/www.lists/www-
talk.1993q1/0182.html)

~~~
rbanffy
I still think the <a ... rel="embed, present">...</a> was a better solution...

~~~
alextp
But it makes it harder to have an image link to something else

~~~
rbanffy
You could always put a <a href...></a> pair around the image, just like we do
with <img ...> tags.

~~~
alextp
Not really, you can't nest <a> tags in html (you can in SVG, though)

------
jparise
_"That’s not to say that all shipping code wins; after all, Andrew and
Intermedia and HyTime shipped code too. Code is necessary but not sufficient
for success."_

That's a good lesson to recognize and appreciate.

~~~
snprbob86
This is so very true. That's why dynamic delivery of Javascript has enabled so
much cool innovation.

Rather than focus on stuffing new tags into HTML, we should focus on pushing
the abstraction level lower. I'd really like to see something along the lines
of a secure/safe <script language="LLVM"/> and an analogously low-level
rendering stack.

There are a lot of good things about HTML, CSS, Javascript, etc, but the
homogeneous designs with heterogeneous implementations are holding back
innovation.

------
blasdel
MIME types are ultimately a folly, as any specific type worth using will
quickly grow into a general container that's no longer useful for the
differentiation that matters to clients. application/xml? image/tiff?
video/mp4? _FUCK ME_

In implementation, it's even worse: the Content-Type in nearly every HTTP
Response on the web is either text/html (default, so it triggers sniffing),
application/octet-stream (because your webserver doesn't know any better), or
sniffed by the webserver from its extension in the filesystem (again, _FUCK
ME_ ).

On the client-side, mouthbreathing open-source developers are always paying
ultimate fealty to Content-Types that were naively sniffed on the server --
_text/x-python_? how could I possibly display that?

~~~
thwarted
_application/octet-stream (because your webserver doesn't know any better)_

application/octet-stream has had to be used for things like .zip files because
Internet Explorer insisted on opening up application/octet stream even the
browser was configured to save it. And to make matters worse, there were some
configurations where Quake3 .pk3 files, which are actually zips, wouldn't save
by Internet Explorer, so you actually needed to rename them to .pk3.zip, which
would sufficiently confuse the browser and prompt to save it.

 _On the client-side, mouthbreathing open-source developers are always paying
ultimate fealty to Content-Types that were naively sniffed on the server --
text/x-python? how could I possibly display that?_

Using a text/* renderer.

~~~
duskwuff
> Using a text/* renderer.

Sadly, Firefox doesn't handle this properly natively. Happily, there's a
plugin for that: <https://addons.mozilla.org/en-US/firefox/addon/8207>

~~~
buro9
This post has raised an unrelated thought:

Why aren't Mozilla using Apple's "There's an app for that" to push "There's a
plugin for that" as a way to counter the rise of Chrome and Safari?

It seems piggy backing off Apple's propaganda that quantity > quality = best
would be an easy thing to do here.

~~~
sp332
Mozilla isn't (currently) interested in countering the rise of Chrome or
Safari. The Mozilla Foundation and the Firefox team are pushing for a more
open, standards-driven web, and both Chrome and Safari are better than IE.
Only after standards are really standard can you have a meaningful competition
on the merits of various browsers.

