Proposed new tag: IMG (1993)(1997.webhistory.org)
1997.webhistory.org
Proposed new tag: IMG (1993)
http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html
21 comments
The thread is fascinating. What I love about it is how the discussion quickly became a variety of proposals for other generalized--and more complicated-- constructs. Lots of discussion on making a generic Mime-based embedded object for example. The worst was "<!ENTITY ICON6 SYSTEM "http://blah..">&ICON6;" Then Marc just ignored the comments, put the <img> tag into Mosaic and it became canon. Would HTML have been so easy for the masses if it was horribly generalized? I'd argue the simplicity of tags like <b>, <img>, <a> made it so popular.
Some suggestions are horrible, but some of the suggestions are pretty good and forward thinking. Allowing img elements to have fallback content would have have the introduction of new image formats (jpg, png, svg) much more painless. We later got the alt-attribute for fallback text, but just using the content for fallback would be both simpler and more powerful.
It is probably a case of worse-is-better. They chose the simplest possible solution and shipped. Introducing the img tag is what made Mosaic dominant.
Later Netscape went to far with worse-is-better. Remember they introduced the <SPACER> tag to allow designers to control whitespace, at a time when Internet Explorer already had shipped with support for CSS padding and margins. Worse-is-better only works when you ship features before the competition, it does not mean worse features will win out over better features.
It is probably a case of worse-is-better. They chose the simplest possible solution and shipped. Introducing the img tag is what made Mosaic dominant.
Later Netscape went to far with worse-is-better. Remember they introduced the <SPACER> tag to allow designers to control whitespace, at a time when Internet Explorer already had shipped with support for CSS padding and margins. Worse-is-better only works when you ship features before the competition, it does not mean worse features will win out over better features.
A generic <include> tag for text/hypertext could have been interesting, particularly if it could be used with link anchors. Although the potential for abuse when including remote content would obvious.
As an astute reader, you rightfully criticize the use of
Another interesting tidbit here is that <img> is modelled as SGML EMPTY element (HTML5 "void" element), a decision that would later complicate integration of XML/XHTML which doesn't support elements without end-element tags.
[1]: http://sgmljs.net/docs/html5.html#transparent-content
<!DOCTYPE HTML [
...
<!ENTITY ICON6
SYSTEM "blah..">
...
]>
<HTML>
...
&ICON6
</HTML>
<!NOTATION GIF SYSTEM>
<!ENTITY ICON6
SYSTEM "blah.."
NDATA GIF>
Another interesting tidbit here is that <img> is modelled as SGML EMPTY element (HTML5 "void" element), a decision that would later complicate integration of XML/XHTML which doesn't support elements without end-element tags.
[1]: http://sgmljs.net/docs/html5.html#transparent-content
Did this go far enough? Imagine if we'd had a gallery element instead:
<gallery type="slideshow" autoscroll="true"> <img src="one.jpg" /> <img src="two.jpg" /> </gallery>
If we'd left that sort of functionality up to the browser imagine the bandwidth saved on tbales for image galleries, javascript carousels, slideshows, etc. Not to mention having more control over elements like autoscroll behavior. Browsers seem to have added just enough functionality for web developers to abuse the document format into an application layer but not enough functionality for a good one.
Also, the first reply to that message (http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.ht...) sounds like the creation of the favicon.
<gallery type="slideshow" autoscroll="true"> <img src="one.jpg" /> <img src="two.jpg" /> </gallery>
If we'd left that sort of functionality up to the browser imagine the bandwidth saved on tbales for image galleries, javascript carousels, slideshows, etc. Not to mention having more control over elements like autoscroll behavior. Browsers seem to have added just enough functionality for web developers to abuse the document format into an application layer but not enough functionality for a good one.
Also, the first reply to that message (http://1997.webhistory.org/www.lists/www-talk.1993q1/0183.ht...) sounds like the creation of the favicon.
Most of the bandwidth for image galleries comes from the images themselves, not the code that runs them.
It's fun to read through this history, while I'm listening to "Where Wizards Stay Up Late".
In reading through the thread [1], I noticed Marc and Jim Davis used an example audio file from the NSA that no longer exists: http://nsa.gov/pub/sounds/gorby.au
Anyone know what the story behind that was? Was that a common example?
[1] http://1997.webhistory.org/www.lists/www-talk.1993q1/0196.ht...
In reading through the thread [1], I noticed Marc and Jim Davis used an example audio file from the NSA that no longer exists: http://nsa.gov/pub/sounds/gorby.au
Anyone know what the story behind that was? Was that a common example?
[1] http://1997.webhistory.org/www.lists/www-talk.1993q1/0196.ht...
Interesting catch!
From the filename and context, I'm going to guess it had something to do with Mikhail Gorbachev?
Searching for that filename yields almost exclusively links to that conversation.
Wayback machine didn't have anything for that URL but they did have a snapshot of the splash page for the NSA website circa 1998: https://web.archive.org/web/20051104005542/http://www.nsa.go...
Archive.org is truly a treasure.
From the filename and context, I'm going to guess it had something to do with Mikhail Gorbachev?
Searching for that filename yields almost exclusively links to that conversation.
Wayback machine didn't have anything for that URL but they did have a snapshot of the splash page for the NSA website circa 1998: https://web.archive.org/web/20051104005542/http://www.nsa.go...
Archive.org is truly a treasure.
It's interesting that the example in the proposal uses the file: protocol rather than http. Was that a mistake? Today a browser would handle such a tag by looking for a local file, rather than "attempt[ing] to pull over the network."
It was probably not a mistake. It was to separate Hypertext from other files. The file: protocol still works in the a browser with a hostname as well. IE: file:///10.1.1.10/files/example.xlsx
I can't believe I didn't know that until now! I've personally used file: only to test local copies of static files/sites, and haven't had a need beyond that.
I wonder how the browser distinguishes between a file residing on a host addressable at 10.1.1.10, and the local path /10.1.1.10/files/example.xlsx. Maybe it tries one and then the other if the first doesn't work.
I wonder how the browser distinguishes between a file residing on a host addressable at 10.1.1.10, and the local path /10.1.1.10/files/example.xlsx. Maybe it tries one and then the other if the first doesn't work.
They would be different URIs.
file://10.1.1.10/files/example.xlsx - remote
vs
file:///10.1.1.10/files/example.xlsx - local
Although it will use the underlying file sharing stack such as NFS or SMB, and not HTTP.
Crazy to see Guido van Rossum comment too:
http://1997.webhistory.org/www.lists/www-talk.1993q1/0259.ht...
http://1997.webhistory.org/www.lists/www-talk.1993q1/0259.ht...
It will never catch on -- just look around HN.
"I think the IMG tag will really drive the web's growth because you could use it for porn."
I remember this. Yes, the web was in black and white for a few months, while Mosaic only supported XBM format.
this is amazing
wonder if [email protected] still works??