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?
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.
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.
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.
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
<!DOCTYPE HTML [
...
<!ENTITY ICON6
SYSTEM "blah..">
...
]>
<HTML>
...
&ICON6
</HTML>
which doesn't make sense as it declares and then references a parsed entity containing HTML.
Of course, what should've been used instead is an SGML data entity:
<!NOTATION GIF SYSTEM>
<!ENTITY ICON6
SYSTEM "blah.."
NDATA GIF>
Interestingly, the discussion also evolves around the anchor tag vs allowing href attributes everywhere to make any element work like a hyperlink, as MathML did. The decision to go with anchor tags complicates HTML to this day. HTML5 uses the (unproven) concept of "transparent content" to specify that the content model of <a> is inherited from the context where <a> is inserted [1].
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.
21 comments
[ 3.3 ms ] story [ 40.2 ms ] threadIn 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...
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.
<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.
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.
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.
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
http://1997.webhistory.org/www.lists/www-talk.1993q1/0259.ht...