Why do we have an IMG element?

I’d like to propose a new, optional HTML tag:

IMG

Required argument is SRC="url".

This names a bitmap or pixmap file for the browser to attempt to pull over the network and interpret as an image, to be embedded in the text at the point of the tag’s occurrence.

An example is:

<IMG SRC="file://foobar.com/foo/bar/blargh.xbm">

(There is no closing tag; this is just a standalone tag.)

This tag can be embedded in an anchor like anything else; when that happens, it becomes an icon that’s sensitive to activation just like a regular text anchor.

Browsers should be afforded flexibility as to which image formats they support. Xbm and Xpm are good ones to support, for example. If a browser cannot interpret a given format, it can do whatever it wants instead (X Mosaic will pop up a default bitmap as a placeholder).

This is required functionality for X Mosaic; we have this working, and we’ll at least be using it internally. I’m certainly open to suggestions as to how this should be handled within HTML; if you have a better idea than what I’m presenting now, please let me know. I know this is hazy wrt image format, but I don’t see an alternative than to just say “let the browser do what it can” and wait for the perfect solution to come along (MIME, someday, maybe).

Xbm and Xpm were popular graphics formats on Unix systems.

“Mosaic” was one of the earliest web browsers. (”X Mosaic” was the version that ran on Unix systems.) When he wrote this message in early 1993, Marc Andreessen had not yet founded the company that made him famous, Mosaic Communications Corporation, nor had he started work on that company’s flagship product, “Mosaic Netscape.” (You may know them better by their later names, “Netscape Corporation” and “Netscape Navigator.”)

“MIME, someday, maybe” is a reference to content negotiation, a feature of HTTP where a client (like a web browser) tells the server (like a web server) what types of resources it supports (like image/jpeg) so the server can return something in the client’s preferred format. The Original HTTP as defined in 1991 (the only version that was implemented in February 1993) did not have a way for clients to tell servers what kind of images they supported, thus the design dilemma that Marc faced.

A few hours later, Tony Johnson replied:

I have something very similar in Midas 2.0 (in use here at SLAC, and due for public release any week now), except that all the names are different, and it has an extra argument NAME="name". It has almost exactly the same functionality as your proposed IMG tag. e.g.

<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">

The idea of the name parameter was to allow the browser to have a set of “built in” images. If the name matches a “built in” image it would use that instead of having to go out and fetch the image. The name could also act as a hint for “line mode” browsers as to what kind of a symbol to put in place of the image.

I don’t much care about the parameter or tag names, but it would be sensible if we used the same things. I don’t much care for abbreviations, ie why not IMAGE= and SOURCE=. I somewhat prefer ICON since it imlies that the IMAGE should be smallish, but maybe ICON is an overloaded word?

Midas was another early web browser, a contemporary of X Mosaic. It was cross-platform; it ran on both Unix and VMS. “SLAC” refers to the Stanford Linear Accelerator Center (now the SLAC National Accelerator Laboratory). SLAC hosted the first web server in the United States (in fact the first web server outside Europe). When Tony wrote this message, SLAC was an old-timer on the WWW, having hosted five pages on their web server for a whopping 441 days.

Tony continued:

While we are on the subject of new tags, I have another, somewhat similar tag, which I would like to support in Midas 2.0. In principle it is:

<INCLUDE HREF="...">

The intention here would be that the second document is to be included into the first document at the place where the tag occured. In principle the referenced document could be anything, but the main purpose was to allow images (in this case arbitrary sized) to be embedded into documents. Again the intention would be that when HTTP2 comes along the format of the included document would be up for separate negotiation.

“HTTP2” is a reference to Basic HTTP as defined in 1992. At this point in early 1993, it was still largely unimplemented. The draft known as “HTTP2” evolved and was eventually standardized as “HTTP 1.0” (albeit not for another three years). HTTP 1.0 did include request headers for content negotiation, a.k.a. “MIME, someday, maybe.”

Tony continued:

An alternative I was considering was:

<A HREF="..." INCLUDE>See photo</A>

I don’t much like adding more functionality to the <A> tag, but the idea here is to maintain compatibility with browsers that can not honour the INCLUDE parameter. The intention is that browsers which do understand INCLUDE, replace the anchor text (in this case “See photo”) with the included document (picture), while older or dumber browsers ignore the INCLUDE tag completely.

This proposal was never implemented, although the idea of text-if-an-image-is-missing is an important accessibility technique which was missing from Marc’s initial <IMG> proposal. Many years later, this feature was bolted on as the <img alt> attribute, which Netscape promptly broke by erroneously treating it as a tooltip.

A few hours after that, Tim Berners-Lee responded:

I had imagined that figues would be reprented as

<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>

where the relation ship values mean

EMBED	 Embed this here when presenting it
PRESENT	 Present this whenever the source document is presented

Note that you can have various combinations of these, and if the browser doesn’t support either one, it doesn’t break.

[I] see that using this as a method for selectable icons means nesting anchors. Hmmm. But I hadn’t wanted a special tag.

This proposal was never implemented, but the rel attribute is still around.

Jim Davis added:

It would be nice if there was a way to specify the content type, e.g.

<IMG HREF="http://nsa.gov/pub/sounds/gorby.au" CONTENT-TYPE=audio/basic>

But I am completely willing to live with the requirement that I specify the content type by file extension.

This proposal was never implemented, but Netscape did later add arbitrary embedding of media objects with the <embed> element.

Jay C. Weber asked:

While images are at the top of my list of desired medium types in a WWW browser, I don’t think we should add idiosyncratic hooks for media one at a time. Whatever happened to the enthusiasm for using the MIME typing mechanism?

Marc Andreessen replied:

This isn’t a substitute for the upcoming use of MIME as a standard document mechanism; this provides a necessary and simple implementation of functionality that’s needed independently from MIME.

Jay C. Weber responded:

Let’s temporarily forget about MIME, if it clouds the issue. My objection was to the discussion of “how are we going to support embedded images” rather than “how are we going to support embedded objections in various media”.

Otherwise, next week someone is going to suggest ‘lets put in a new tag <AUD SRC="file://foobar.com/foo/bar/blargh.snd">‘ for audio.

There shouldn’t be much cost in going with something that generalizes.

With the benefit of hindsight, it appears that Jay’s concerns were well-founded. It took a little more than a week, but HTML5 did finally add new <video> and <audio> elements.

Responding to Jay’s original message, Dave Raggett said:

True indeed! I want to consider a whole range of possible image/line art types, along with the possibility of format negotiation. Tim’s note on supporting clickable areas within images is also important.

Later in 1993, Dave Raggett proposed HTML+ as an evolution of the HTML standard. The proposal was never implemented, and it was superceded by HTML 2.0. HTML 2.0 was a “retro-spec,” which means it formalized features already in common use. “This specification brings together, clarifies, and formalizes a set of features that roughly corresponds to the capabilities of HTML in common use prior to June 1994.”

Dave later wrote HTML 3.0, based on his earlier HTML+ draft. HTML 3.0 was also never implemented (outside of the W3C’s own reference implementation, Arena), and it was superceded by HTML 3.2. HTML 3.2 was also a “retro-spec” — “HTML 3.2 adds widely deployed features such as tables, applets and text flow around images, while providing full backwards compatibility with the existing standard HTML 2.0.”

Dave later co-authored HTML 4.0 and developed HTML Tidy, and went on to help with XHTML, XForms, MathML, and other modern W3C specifications.

Getting back to 1993, Marc replied to Dave:

Actually, maybe we should think about a general-purpose procedural graphics language within which we can embed arbitrary hyperlinks attached to icons, images, or text, or anything. Has anyone else seen Intermedia’s capabilities wrt this?

Intermedia was a hypertext project from Brown University. It was developed from 1985 to 1991 and ran on A/UX, a Unix-like operating system for early Macintosh computers.

The idea of a “general-purpose procedural graphics language” did eventually catch on. Modern browsers support both SVG (declarative markup with embedded scripting) and <canvas> (procedural direct-mode graphics API), although the latter started as a proprietary extension before being “retro-specced” by the WHATWG.

Bill Janssen replied:

Other systems to look at which have this (fairly valuable) notion are Andrew and Slate. Andrew is built with _insets_, each of which has some interesting type, such as text, bitmap, drawing, animation, message, spreadsheet, etc. The notion of arbitrary recursive embedding is present, so that an inset of any kind can be embedded in any other kind which supports embedding. For example, an inset can be embedded at any point in the text of the text widget, or in any rectangular area in the drawing widget, or in any cell of the spreadsheet.

“Andrew” is a reference to the Andrew User Interface System (although at that time it was simply known as the Andrew Project).

Meanwhile, Thomas Fine had a different idea:

Here’s my opinion. The best way to do images in WWW is by using MIME. I’m sure postscript is already a supported subtype in MIME, and it deals very nicely with mixing text and graphics.

But it isn’t clickable, you say? Yes your right. I suspect there is already an answer to this in display postscript. Even if there isn’t the addition to standard postscript is trivial. Define an anchor command which specifies the URL and uses the current path as a closed region for the button. Since postscript deals so well with paths, this makes arbitrary button shapes trivial.

Display Postscript was an on-screen rendering technology co-developed by Adobe and NeXT.

This proposal was never implemented, but the idea that the best way to fix HTML is to replace it with something else altogether still pops up from time to time.

Tim Berners-Lee, March 2, 1993:

HTTP2 allows a document to contain any type which the user has said he can handle, not just registered MIME types. So one can experiment. Yes I think there is a case for postscript with hypertext. I don’t know whether display postcript has enough. I know Adobe are trying to establish their own postscript-based “PDF” which will have links, and be readable by their proprietory brand of viewers.

I thought that a generic overlaying language for anchors (Hytime based?) would allow the hypertext and the graphics/video standards to evolve separately, which would help both.

Let the IMG tag be INCLUDE and let it refer to an arbitrary document type. Or EMBED if INCLUDE sounds like a cpp include which people will expect to provide SGML source code to be parsed inline — not what was intended.

HyTime was an early, SGML-based hypertext document system. It loomed large in many early discussions of HTML, and later XML.

Tim’s proposal for an <INCLUDE> tag was never implemented, although you can see echoes of it in <object>, <embed>, and the <iframe> element.

Finally, on March 12, 1993, Marc Andreessen revisited the thread:

Back to the inlined image thread again — I’m getting close to releasing Mosaic v0.10, which will support inlined GIF and XBM images/bitmaps, as mentioned previously. …

We’re not prepared to support INCLUDE/EMBED at this point. … 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 don’t really know why I wrote this. It wasn’t what I set out to write. That happens. But I am extraordinarily fascinated with all aspects of this almost-17-year-old conversation. Consider:

• HTTP still exists. HTTP successfully evolved from 0.9 into 1.0 and later 1.1. And still it evolves.
• HTML still exists. That rudimentary data format — it didn’t even support inline images! — successfully evolved into 2.0, 3.2, 4.0. And still it, too, evolves. HTML is an unbroken line. A twisted, knotted, snarled line, to be sure. There were plenty of “dead branches” in the evolutionary tree, places where standards-minded people got ahead of themselves (and ahead of authors and implementors). But still. Here we are, in 2009, and web pages from 1990 still render in modern browsers. I just loaded one up on my Android phone, and I didn’t even get prompted to “please wait while importing legacy format…”
• HTML has always been a conversation between browser makers, authors, standards wonks, and other people who just showed up and liked to talk about angle brackets. Most of the successful versions of HTML have been “retro-specs,” catching up to the world while simultaneously trying to nudge it in the right direction. Anyone who tells you that HTML should be kept “pure” (presumably by ignoring browser makers, or ignoring authors, or both) is simply misinformed. HTML has never been pure, and all attempts to purify it have been spectacular failures, matched only by the attempts to replace it.
• None of the browsers from 1993 still exist in any recognizable form. Netscape Navigator was abandoned in 1998 and rewritten from scratch to create the Mozilla Suite, which was then forked to create Firefox. Internet Explorer had its humble “beginnings” in “Microsoft Plus! for Windows 95,” where it was bundled with some desktop themes and a pinball game. (But of course that browser can be traced back further too.)
• Some of the operating systems from 1993 still exist, but none of them are relevant to the modern web. Most people today who “experience” the web do so on a PC running Windows 2000 or later, a Mac running Mac OS X, a PC running some flavor of Linux, or a handheld device like an iPhone. In 1993, Windows was at version 3.1 (and competing with OS/2), Macs were running System 7, and Linux was distributed via Usenet. (Want to have some fun? Find a graybeard and whisper “Trumpet Winsock” or “MacPPP.”)
• Some of the same people are still around and still involved in what we now simply call “web standards.” That’s after almost 20 years. And some were involved in predecessors of HTML, going back into the 1980s and before.
• Speaking of predecessors… With the eventual popularity of HTML and the web, it is easy to forget the contemporary formats and systems that informed its design. Andrew? Intermedia? HyTime? And HyTime was not some rinky-dink academic research project; it was an ISO standard. It was approved for military use. It was Big Business. And you can read about it yourself… on this HTML page, in your web browser.

But none of this answers the original question: why do we have an <img> element? Why not an <icon> element? Or an <include> element? Why not a hyperlink with an include attribute, or some combination of rel values? Why an <img> element? Quite simply, because Marc Andreessen shipped one, and shipping code wins.

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. And I certainly don’t mean to say that shipping code before a standard will produce the best solution. Marc’s <img> element didn’t mandate a common graphics format; it didn’t define how text flowed around it; it didn’t support text alternatives or fallback content for older browsers. And 16, almost 17 years later, we’re still struggling with content sniffing, and it’s still a source of crazy security vulnerabilities. And you can trace that all the way back, 17 years, through the Great Browser Wars, all the way back to February 25, 1993, when Marc Andreessen offhandedly remarked, “MIME, someday, maybe,” and then shipped his code anyway.

The ones that win are the ones that ship.

§

Fifty five comments here (latest comments)

1. “March 12, 2003″? I hope you’re ten years off.

   — Jesper 

2. Bah. Fixed.

   — Mark 

3. Some of the operating systems from 1993 still exist, but none of them are relevant to the modern web. Most people today who “experience” the web do so on a PC running Windows 2000 or later, a Mac running Mac OS X.

   Actually, MacOSX carries a huge legacy from NextStep (greater, many would say, than its legacy from Classic MacOS). NextStep was not only around in 1993, it was the OS on which the Web was invented.

   — Jacques Distler 

4. Terrific post. I particularly like the reminder that HTML is not utopian. There is no YEAR ZERO for HTML. It’s a conversation:

   HTML has always been a conversation between browser makers, authors, standards wonks, and other people who just showed up and liked to talk about angle brackets. Most of the successful versions of HTML have been “retro-specs,” catching up to the world while simultaneously trying to nudge it in the right direction. Anyone who tells you that HTML should be kept “pure” (presumably by ignoring browser makers, or ignoring authors, or both) is simply misinformed. HTML has never been pure, and all attempts to purify it have been spectacular failures, matched only by the attempts to replace it.

   — Joe Crawford 

5. Who are you calling a graybeard?

   As it happens, I now live right around the corner from the old MacSLIP office, where I picked up my copy mumblemumble years ago.

   — Adam Rice 

6. IMG tags – Ataxia (pingback)

7. Xbm and Xpm were popular graphics formats on Unix systems. They are still supported in modern browsers. (I tested in Internet Explorer 8 and Google Chrome.)

   IE8 is not a modern browser.

   — Rob 

8. I’d always had hope for SMIL catching on someday. Alas.

   — Anil 

9. Awesome post. Thanks for the interesting history.

   — Andy 

10. Shipping doesn’t mean you win, but not shipping means you lose.

    — Steve 

11. Great post, definitely interesting to read, considering I remember ‘craving’ Netscape Navigator to start learning about the web and HTML – this was when I was 10 or 11, and I remember Netscape Navigator being bundled with a book that taught you web design – wow how times have changed!

    — Jason 

12. A/UX is a Unix.

    — rshxd 

13. Greybeard!? I’m under 30 and I remember (not fondly, I assure you) fighting with both Trumpet Winsock *and* MacPPP!

    — Brian 

14. Great article. It’s great to take a look back and see how far we have come, though that include tag would of been handy.

    — Ryan 

15. love this. i hope i can contribute well to the future.

    — typesett 

16. To me standards work has always had an air of self-importance that it didn’t deserve, but after reading this, I feel more of the fun game of trying things and seeing what sticks.

    — Thomas 

17. It’s the Stanford linear accelerator, not the “Standard” linear accelerator…

    — miguel 

18. Very nice post. It’s fun to think about a world in which the cement we take for granted now is as pliable as our current ideas.

    — Adam Barth 

19. Also under 30, and just had a flash of nostalgia about the sheer feeling of triumph when MacPPP would successfully connect my old Performa (through my Global Village TelePort!) to Earthlink (having weaned my family off AOL.)

    Connecting to Wi-Fi just isn’t the same.

    — Len 

20. So, you are saying that if Microsoft ships support for InfoPath processing instructions and proprietary elements in IE we’ll have them all over pretty soon?

    — Peter 

21. I know my Google-fu may not be very good, but I was unable to find support for XPM in any browser that I had heard of. As for XBM, support was removed from Firefox 3.next on the 29th of July, and you apparently need a registry edit to enable it in IE, although I was unable to get that to work.

    — Neil 

22. Interesting post. Loved the conversation about the formats. Kinda applies to the HTML5 video/audio tag discussions, doesn’t it?

    — Rakesh Pai 

23. X Mosaic (also known as NSCA Mosaic) where not renamed to Netscape Navigator. While Marc Andreessen where involved in both, and they had a similar name at one point, NSCA Mosaic and Netscape Navigator is usually considered two different browsers.

    — HK 

24. All those malformed snippets wake me wince in a post-XML world. I suppose at the time, element and attribute casing & quoting were fairly arbitrary.
    Tag-soup (aka street HTML) seems to have been very acceptable in these discussions, rather than just the later consequence of tolerant browser parsing.

    — James Pearce 

25. NCSA X Mosaic and Netscape are unrelated browsers.
    Many people also make the same mistake about Spyglass Mosaic and NCSA Mosaic – including Wikipedia: http://upload.wikimedia.org/wikipedia/commons/7/74/Timeline_of_web_browsers.svg

    “Yes, we licensed the technology and trademarks from NCSA (at the University of Illinois), but we never used any of the code.”
    - Eric Sink, Spyglass Mosaic project lead.

    — RichB 

26. Can I call you Gandalf and buid a shrine? Thanks a lot for such writing such excellent posts.

    — Divya 

27. Fantastic history! (now on reddit homepage).

    — Yvo 

28. Great read. Your writing continues to draw me in: Dive Into Mark/Python/HTML5 and your WHATWG posts are deliciously packed with information and links. Cheers.

    — Adam Backstrom 

29. I hate content sniffing with an unending passion (and not just on the web, mind you; file(1) and magic(4) are the spawn of Satan). The idea that one can rely on figuring out the type/format of a file by examination of the byte stream is one of the worst mistakes ever made in the history of computing, in my opinion (it’s unclear whether that or file typing extension is actually the worst). For me, IE actually deserves those vulnerabilities.

    — Pierre Lebeaupin 

30. That was a great trip back in time. Now can you explain why we have DIV tags? I’d like to eventually kill them off -> http://www.russellheimlich.com/blog/death-to-the-div/

    — Russell Heimlich 

31. Great post. Thanks.

    — KT 

32. I’m 25 and I think I’m at the cutoff of the youngest people who remember trumpet winsock. Anyway, I’m concerned your notion of “shipping code wins” is an endorsement to Microsoft’s policy of doing whatever the heck they want and standardizing it later by killing the competition, or taking over the standards body. A standard without a good reference implementation loses. Not shipping the code loses. But shipping alone is insufficient.

    — Z.T. 

33. Z.T.: I believe “shipping code wins” was meant to be a conclusion based on empirically observed facts. I don’t think Mark was advocating shipping whatever the hell you want, standards be damned.

    — Karl von L. 

34. Great post, Mark,

    Re: James Pearce’s comment:

    All those malformed snippets wake me wince in a post-XML world. I suppose at the time, element and attribute casing & quoting were fairly arbitrary.

    Not so much arbitrary, but “up to the individual”–because well-formed SGML allows for that–more flexibility / variety in the markup than XML.

    Compared with XML, with SGML, there was more concern that markup should be able to adapt to individual content and authoring idiosyncrasies. And, pre-web, there wasn’t much hindsight about what happens when tens of thousands of people are authoring in the same few markup syntaxes and expecting compatible output from many general purpose parsers / reader-apps.

    XML has more of an idea about markup conformity, e.g., to make for a simpler DOM that’s easier to parse and work with.

    — Jay Fienberg 

35. Random comment: Gecko no longer supports XBM, I’m not sure whether Safari does, and Chrome has a bug on file for removing that support soon.

    — Peter Kasting 

36. 23, hardly any gray hears at all, and already used MacPPP ;-) Great post nevertheless, and to be honest, I feel almost flattered to be called a “graybeard”.

    — Stephan 

37. Nice article, but a few corrections:

    Andreessen’s browser was just called “Mosaic”, or officially “NCSA Mosaic” since it was developed at the National Center For Supercomputing Applications at the University of Illinois. “X Mosaic” just refers the X-Windows implementation; there were also Mac Mosaic and Windows Mosaic.

    The company Andreessen co-founded was called Mosaic and the new browser he wrote was called Netscape. But before they shipped, NCSA blocked them from using that company name, so they renamed the company Netscape and disambiguated the browser by calling it Netscape Navigator.

    Firefox doesn’t directly descend from Netscape Navigator. The whole point of the Mozilla project that resulted in Firefox was to throw out the awful Navigator source code and rewrite everything.

    — Anonymous 

38. Just want to say thank you for a great article!

    — Chris L 

39. OK, I think I’ve fixed all of the Mosaic/Netscape/Mozilla/Firefox lineage bits. Sorry for the confusion.

    — Mark 

40. “Real artists ship.” –Steve Jobs

    — Alderete 

41. Woohoo! Always fun to see mentions of Intermedia. I was the principal engineer who implemented the structured graphics component of Intermedia that included graphical anchors and hypertext links.

    I believe the key innovation of HTTP and HTML was a more-or-less open spec that gave anyone the ability to set up their own servers. In many ways HTML is the ultimate example of the “worse is better” principle.

    Anyways, Intermedia shipped, but it was bound up in a lan-based networking model, and using A/UX made it really hard to distribute widely.

    — Charlie Evett 

42. The latest Webkit nightly running on SnowLeopard supports XBM.

    — drew 

43. Opera 10 still supports XBM.

    — Shmuel 

44. Insightful article documenting some of the early discussions around HTML. Many thanks for taking the time to put this together!!

    — Jon Jackson 

45. Sometimes crap things that deserve to die get lucky. HTML is one of those things.

    — Mike 

46. @anonymous> “The company Andreessen co-founded was called Mosaic and the new browser he wrote was called Netscape. But before they shipped, NCSA blocked them from using that company name,”

    IIRC, MCC shipped Netscape late summer 2004 with the Mosaic Communications Corp company name, but only became Netscape with the 1.1N version (which used the Netscape logo/throbber icon from a competition).

    I wish I could purge this useless crap from my brain and remember useful things instead.

    — RichB 

47. Oh wow this post has brought up so many memories!
    I can barely remember MacSLIP; I remember MacPPP being krotchety; and I remember FreePPP (and it’s monkey) being an awesome replacement eventually.

    — Ryan Jay Schotte 

48. I agree with your sentiments – getting it done is sometimes more important than getting it “right”.

    — Ben 

49. “Some of the operating systems from 1993 still exist, but none of them are relevant to the modern web.” … “In 1993, [...] Linux was distributed via Usenet”.

    Slackware 1.0 was released in 1993, and distributed over FTP. (I’m sure it was also distributed over USENET, because everything was distributed over USENET, and still is.) The path from 1993 Linux to 2009 Linux is at least as direct as the path from 1993 HTML to 2009 HTML.

    — Slacker 

50. Oh man, MacPPP, those were the days, Zipping into The Dorsai Embassy in Long Island City, getting excited over that hot new 14.4k modem to replace the ol’ 2400 bad boy… Nostalgia!

    — Justin D 

51. Man, I loved reading this. Thank you!

    — John Walker 

52. The real lesson here is this:

    HTML and HTTP were hobby projects for geniuses working at particle accelerators.

    Full time, salaried positions for thinking about inane alt text features of pictures on the web is a secondary, or even tertiary effect of a global asset bubble that is in (initial) process of popping.

    As we cross the event horizon of real deflation, most of you folks would be well advised to learn a trade of some kind. Unless you’re working at the accelerator.

    — Graybeard 

53. As we cross the event horizon of real deflation, most of you folks would be well advised to learn a trade of some kind. Unless you’re working at the accelerator.

    If we are, indeed, facing such an economic calamity, I can assure you the high energy physics (”the accelerator”) will be the first thing on the chopping block. In such an eventuality, what “most of you folks” have to fear is a flood of very smart ex-physicists seeking IT jobs.

    Full disclosure: I’m a high energy physicist, for whom this stuff is, indeed, a “hobby project”.

    — Jacques Distler 

54. This was an awesome read. Thanks!

    — Laurie 

55. Historia del tag “img” : Dorsumi - D-news - Dorsuminews (pingback)