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