Hacker News new | comments | show | ask | jobs | submit login
Why do we have an IMG element? (diveintomark.org)
148 points by gthank on Nov 3, 2009 | hide | past | web | favorite | 13 comments

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."


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

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

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

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

"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.

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.

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?

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.

> 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

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.

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.

down-voted for swearing witch all caps.

Applications are open for YC Winter 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact