On February 25, 1993, Marc Andreessen wrote:
I'd like to propose a new, optional HTML tag:
Required argument is
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:
(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).
“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
<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
SOURCE=. I somewhat prefer
ICONsince it imlies that the
IMAGEshould be smallish, but maybe
ICONis 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.
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:
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.”
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
INCLUDEparameter. 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
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 meanEMBED 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.
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
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?
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.
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.
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.”
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?
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.
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.
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.
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.
INCLUDEand let it refer to an arbitrary document type. Or
INCLUDEsounds 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
<embed>, and the
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
EMBEDat this point. ... So we're probably going to go with
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:
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.
So I was researching the history of the tilde, because D told me that her company just installed a new web proxy that denies access to any URL with a tilde in it. Presumably because the presence of a tilde indicates with remarkable accuracy a personal site, and apparently her employer believes that reading personal sites is not an appropriate use of company time. Which, to be honest, is probably accurate, given the nature of her work. But never mind that. I don't want to talk about corporate politics. I want to talk about the tilde.
Every command-line-loving geek will tell you that ~ stands for
home directory, and cd ~ will take you to your home directory. (cd ~username will take you to someone else's, except on Mac OS X, where it will take you to their Public file sharing directory.) It is from this heritage that we can trace the present-day practice of using tildes in URLs to denote personal pages, since one single system-wide configuration allowed individual users to have their own web sites by storing files in their own home directory. Or, more commonly now that Apache has taken over the world, in their public_html subdirectory, except on Mac OS X, where if you turn on web sharing and point your browser to http://
But I don't want to talk about Mac OS X. I want to talk about the tilde.
As with so many other things, I find that Jukka Korpela is the expert in this field. Jukka is no doubt a member of my karass, a word which Google (old habits die hard) feels is best explained by the personal site of Eugene Wallingford, which, like Jukka's home page, can not be referenced without a tilde.
In fact, Jukka has written a lengthy treatise on why the tilde should not be used in URLs, a treatise which, I feel obliged to point out, contains a tilde in its URL.
Clearly, the tilde is underappreciated.
Digging further, we find this post of Jukka's from 1998, in which we learn that the tilde was not meant to be the tilde at all, but rather an odd character called the overline. Presumably to balance out the underline, if indeed those sorts of things require balance. There is balance in the universe, to be sure, but I am less sure that it eminates from my keyboard. No matter. The tilde was the tilde so that Spanish-typing types could type the ñ (now referenced in HTML as the named entity ñ), but somewhere along the line, it morphed into a general-purpose character with all sorts of geeky uses.
Digging even further, it appears that the tilde was originally an alternate for #, then an alternate for ^, and its life as an overline replacement came even later. Jukka confirms this and adds a timeline: 1963 for #, 1964 for ^, 1966 for overline. Then June 30, 1966, the watershed moment in an X3 committee meeting, when it was proposed
as exclusively a tilde in USA to appease SHARE.
I can find no further reference as to what this acronym means, or what this committee meeting was about. According to Sam Ruby, SHARE is share.org, and according the Tim Bray (via email), SHARE was the original IBM users group, and quite powerful in the days when
IBM mainframe. According to David Ross, SHARE stood for
Society to Help Avoid Redundant Effort, and was created for the free exchange of software long before anyone thought software could be copyrighted or patented. According to this history of IBM's Advanced Computing Systems (a page which, I feel obliged to point out, contains a tilde in its URL), the NSA visited ACS in 1966 for a
full presentation. I am in no way suggesting that the invention of the tilde was a government conspiracy.
The next reference in Jukka's history isn't until 1991, when the tilde was officially added to ISO-646. But there's so much to learn in between.
And now, down the rabbit hole we go. Scouring Usenet (which the kids of yesterday called
Deja News, and kids today call
Google Groups), we find a reprint of a 1991 William Safire (yes, that William Safire) article On Language, in which we learn that ~ is officially pronounced
squiggle. This is confirmed by the Jargon Dictionary to this very day. I'm not sure this is useful, but I just thought it was cool to see William Safire writing about the proper pronunciation of various ASCII characters.
As early as August 1990, tilde was included in the waka waka bang splat poem.
In July 1989, Kermit gained support for filenames containing a tilde.
In February 1988, an editor's note to an otherwise unrelated article notes that Fidonet supported ASCII characters space through tilde.
As early as January 1987, less used the tilde to denote lines past EOF.
As early as July 1986, troff supported the tilde.
In November 1985, a mod.sources post refers to Bourne shell enhancements (history,tilde,job control).
In April 1983, tilde was causing bugs in vi (actually due to underlying bugs in csh).
And that's the earliest reference I can find. Jim Lyon (yes, that Jim Lyon) has contacted me to point out that section 3.4.1 of the INTERCAL Programming Language Revised Reference Manual, which he co-authored in 1973 (and which, like everything else that is good and pure in this world, contains a tilde in its URL), refers to the tilde as a
sqiggle. Not a
squiggle, mind you, but a
sqiggle, a difference which Jim assures me was quite intentional and most likely original. This alternate spelling is still listed in the Jargon Dictionary, complete with pronunciation guide.
The tilde (sqiggle) was the select operator in INTERCAL, and is so incredibly heinous that I feel compelled to quote the manual at length:
The select operator takes from the first operand whichever bits correspond to 1's in the second operand, and packs these bits to the right in the result. Both operands are automatically padded on the left with zeros to 32 bits before the selection takes place, so the variable types are unrestricted. The resulting value will have the same type as the second operand. For example, #179~#201 (binary value 10110011~11001001) selects from the first argument the 8th, 7th, 4th, and 1st from last bits, namely, 1001, which = 9. But #201~#179 selects from binary 11001001 the 8th, 6th, 5th, 2nd, and 1st from last bits, giving 10001 = 17. #179~#179 has the value 31, while #201~#201 has the value 15.
Following up on Sam Ruby's links, we find that the tilde was not a part of ASCII-1963, the first standardized version of ASCII (standardized in 1963, hence the name), but it was part of ASCII-1965, added along with its friends, ^, _, and @. This would seem to contradict Jukka's version, which places the tilde as a replacement for # as early as 1963. Perhaps it was, but didn't make it into the ASCII standard. At any rate, IBM (and therefore SHARE, IBM's users group) was, at the time, centered around their own (competing) character encoding standard, EBCDIC. Original EBCDIC (1964)
did not include a tilde, but it was added in Augmented EBCDIC after the ISO included it in ISO 8859-1. Correction: Original EBCDIC did include the tilde. My mistake! ... This still doesn't explain why SHARE would be so pro-tilde in 1966 (or rather, why anyone else would be anti-tilde, since it was included in both EBCDIC and ASCII by then), but I believe we can pinpoint the birth of the tilde as its own character sometime between 1963 and 1964. And it does now appear that IBM was the father of the tilde, unless someone else can find a reference to it in a character set prior to 1964.
So where does this leave us? Unsatisfied, no doubt. There is history here, but there are gaps. What happened at that watershed meeting in 1966? How did the tilde rise to prominence in the 1980s? When did it become a synonym for
home directory? When did it migrate into the world of web servers to provide a cheap and simple way of giving individual users their own web sites? I don't know, and the lateness of the hour prevents me from continuing my research, a failing for which I apologize profusely. Goodnight, goodnight. May you dream of tildes, stars, and whorls.
The CERN/W3C web server added support for ~username in 1994. Change notes (sorry, no direct link to the relevant version, they don't have anchors on that page) for version 2.15beta, released 11 February 1994, say this:User-supported directories enabling URLs starting with /~username. ...
NCSA's web server is more difficult. The version history page first mention of the feature, I think, at version 1.0a4. ... Grabbing the old versions from their ftp server, the feature wasn't in 0.5 but it was in 1.1 (obviously), which was apparently released somewhere around March 25th, 1994. ... I find one mention of this feature asnewishon NCSA at 1993-11-18. A bit earlier is 1993-09-30. ... Guessing would place it somewhere in the summer or autumn of 1993.
Update #2: Rich Salz points me to the UUCP Implementation Description, dated October 31, 1978. UUCP was the UNIX dialup networking system, and came bundled with version7 UNIX. To quote from the UUCP manual:
The source and/or destination names may also contain a ~user prefix. This translates to the login directory on the specified system. ... The command
uucp\ \ usg!~dan/*.h\ \ ~danwill set up the transfer of files whose names end with.hin dan's login directory on systemusgto dan's local login directory.
Rich contacted the original author of UUCP to find out why he chose the tilde for this purpose, but the author doesn't remember. Probably the best guess is because all the good characters were taken. Rich believes that UUCP was the first to use the tilde to mean
home directory, then later the C shell copied the syntax from UUCP. And the rest, as they say, is history.