NETSCAPE'S UNTOLD WEBSTORIES
2024-02-02
I mentioned yesterday that during Bloganuary I'd put non-Bloganuary-prompt
post ideas onto the backburner, and considered extending my daily streak by
posting them in February. Here's part of my attempt to do that:
Let's take a trip into the Web of yesteryear, with thanks to our friends at
the Internet Archive's WayBack Machine.
The page we're interested in used to live at
http://www.netscape.com/comprod/columns/webstories/index.html, and promised to
be a showcase for best practice in Web development. Back in October 1996, it
looked like this:
(IMG) Screenshot from Netscape Columns: Web Site Stories: a Coming Soon page which says "The series is scheduled to debut in November."
The page is a placeholder for Netscape Webstories (or Web Site Stories, in
some places). It's part of a digital magazine called Netscape Columns which
published pieces written by Marc Andreeson, Jim Barksdale, and other bigwigs
in the hugely-influential pre-AOL-acquisition Netscape Communications.
This new series would showcase best practice in designing and building Web
sites (Yes, we used to write "Web sites" as two words. We also used to
consistently capitalise the words Web and Internet. Some of us still do so.),
giving a voice to the technical folks best-placed to speak on that topic. That
sounds cool!
Those white boxes above and below the paragraph of text aren't missing images,
by the way: they're horizontal rules, using the little-known size attribute to
specify a thickness of <hr size=4>! (In case it's not clear, this blog post is
going to be as much about little-known and archaic Web design techniques as it
is about Netscape's website.)
Certainly you're excited by this new column and you'll come back in November
1996, right?
(IMG) Screenshot from Netscape Columns: Web Site Stories: a Coming Soon page which says "The series is scheduled to begin in January."
Oh. The launch has been delayed, I guess. Now it's coming in January.
The <hr>s look better now their size has been reduced, though, so clearly
somebody's paying attention to the page. But let's take a moment and look at
that page title. If you grew up writing web pages in the modern web, you might
anticipate that it's coded something like this:
<h2 style="font-variant: small-caps; text-align: center;">Coming Soon</h2>
There's plenty of other ways to get that same effect. Perhaps you prefer
font-feature-settings: 'smcp' in your chosen font; that's perfectly valid.
Maybe you'd use margin: 0 auto or something to centre it: I won't judge.
But no, that's not how this works. The actual code for that page title is:
<center>
<h2>
<font size="+3">C</font>OMING
<font size="+3">S</font>OON
</h2>
</center>
Back when this page was authored, we didn't have CSS (This is a white lie. CSS
was first proposed almost at the same time as the Web! Microsoft Internet
Explorer was first to deliver a partial implementation of the initial
standard, late in 1996, but Netscape dragged their heels, perhaps in part
because they'd originally backed a competing standard called JavaScript Style
Sheets (JSSS). JSSS had a lot going for it: if it had enjoyed widespread
adoption, for example, we'd have had the equivalent of CSS variables a full
twenty years earlier! In any case, back in 1996 you definitely wouldn't want
to rely on CSS support.). The only styling elements were woven right in
amongst the semantic elements of a page (Wondering where the text and link
colours come from? <body bgcolor="#ffffff" text="#000000" link="#0000ff"
vlink="#ff0000" alink="#ff0000">. Yes really, that's where we used to put our
colours.). It was simple to understand and easy to learn... but it was a total
mess (Personally, I really loved the aesthetic Netscape touted when using
Times New Roman (or whatever serif font was available on your computer:
webfonts weren't a thing yet) with temporary tweaks to font sizes, and I
copied it in some of my own sites. If you look back at my 2018 blog post
celebrating two decades of blogging, where I've got a screenshot of my blog as
it looked circa 1999, you'll see that I used exactly this technique for the
ordinal suffixes on my post dates! On the same post, you'll see that I
somewhat replicated the "feel" of it again in my 2011 design, this time using
a stylesheet.).
Anyway, let's come back in January 1997 and see what this feature looks like
when it's up-and-running.
(IMG) Screenshot from Netscape Columns: Web Site Stories: a Coming Soon page which says "The series is scheduled to begin in the spring."
Nope, now it's pushed back to "the spring".
Under Construction pages were all the rage back in the nineties. Everybody had
one (or several), usually adorned with one or more of about a thousand
different animated GIFs for that purpose. (There's a whole section of
Cameron's World dedicated to "under construction" banners, and that's a
beautiful thing!)
(GIF) Rotating animated "under construction" banner.
Building "in public" was an act of commitment, a statement of intent, and an
act of acceptance of the incompleteness of a digital garden. They're sort-of
coming back into fashion in the interpersonal Web, with the "garden and
stream" metaphor (The idea of "garden and stream" is that you publish early
and often, refining as you go, in your garden, which can act as an extension
of whatever notetaking system you use already, but publish mostly "finished"
content to your (chronological) stream. I see an increasing number of IndieWeb
bloggers going down this route, but I'm not convinced that it's for me.)
taking root. This isn't anything new, of course - Mark Bernstein touched on
the concepts in 1998 - but it's not something that I can ever see returning to
the "serious" modern corporate Web: but if you've seen a genuine, non-ironic
"under construction" page published to a non-root page of a company's website
within the last decade, please let me know!
(GIF) Under construction banner with an animated yellow-and-black tape banner between two "men at work" signs.
RSS doesn't exist yet (although here's a fun fact: the very first version of
RSS came out of Netscape!). We're just going to have to bookmark the page and
check back later in the year, I guess...
(IMG) Screenshot from Netscape Columns: Web Site Stories: a Coming Soon page identical to the previous version but with a search box ("To search the Netscape Columns, type a word or phrase here:") beneath.
Okay, so February clearly isn't Spring, but they've updated the page... to add
a search form.
It's a genuine <form> tag, too, not one of those old-fashioned <isindex> tags
you'd still sometimes find even as late as 1997. Interestingly, it specifies
enctype="application/x-www-form-urlencoded". Today's developers probably don't
think about the enctype attribute except when they're doing a form that
handles file uploads and they know they need to switch it to
enctype="multipart/form-data", (or their framework does this automatically for
them!).
But these aren't the only options, and some older browsers at this time still
defaulted to enctype="text/plain". So long as you're using a POST and not GET
method, the distinction is mostly academic, but if your backend CGI program
anticipates that special characters will come-in encoded, back then you'd be
wise to specify that you wanted URL-encoding or you might get a nasty surprise
when somebody turns up using LMB or something equally-exotic.
Anyway, let's come back in June. The content must surely be up by now:
(IMG) Screenshot from Netscape Columns: Web Site Stories: a Coming Soon page which says "The series is scheduled to begin in August."
Oh come on! Now we're waiting until August?
At least the page isn't abandoned. Somebody's coming back and editing it from
time to time to let us know about the still-ongoing series of delays. And
that's not a trivial task: this isn't a CMS. They're probably editing the
.html file itself in their favourite text editor, then putting the appropriate
file:// address into their copy of Netscape Navigator (and maybe other
browsers) to test it, then uploading the file - probably using FTP - to the
webserver... all the while thanking their lucky stars that they've only got
the one page they need to change.
We didn't have scripting languages like PHP yet, you see (Another white lie.
PHP was released way back in 1995 and even the very first version supported
something a lot like server-side includes, using the syntax <!--include
/file/name.html-->. But it was a little computationally-intensive to run
willy-nilly.). We didn't really have static site generators. Most servers
didn't implement server-side includes. So if you had to make a change to every
page on a site, for example editing the main navigation menu, you'd probably
have to open and edit dozens or even hundreds of pages. Little wonder that
framesets caught on, despite their (many) faults, with their ability to render
your navigation separately from your page content.
Okay, let's come back in August I guess:
(IMG) Screenshot from Netscape Columns: Web Site Stories: a Coming Soon page which says "The series is scheduled to begin in the spring." Again.
Now we're told that we're to come back... in the Spring again? That could mean
Spring 1998, I suppose... or it could just be that somebody accidentally
re-uploaded an old copy of the page.
Hey: the footer's gone too? This is clearly a partial re-upload: somebody
realised they were accidentally overwriting the page with the previous-but-one
version, hit "cancel" in their FTP client (or yanked the cable out of the
wall), and assumed that they'd successfully stopped the upload before any
damage was done.
They had not.
(IMG) Screenshot of a Windows 95 dialog box, asking "Are you sure you want to delete index.html?" The cursor hovers over the "Yes" button.
I didn't mention that top menu, did I? It looks like it's a series of links,
styled to look like flat buttons, right? But you know that's not possible
because you can't rely on having the right fonts available: plus you'd have to
do some <table> trickery to lay it out, at which point you'd struggle to
ensure that the menu was the same width as the banner above it. So how did
they do it?
The menu is what's known as a client-side imagemap. Here's what the code looks
like:
<a href="/comprod/columns/images/nav.map">
<img src="/comprod/columns/images/websitestories_ban.gif" width=468 height=32 border=0 usemap="#maintopmap" ismap>
</a><map name="mainmap">
<area coords="0,1,92,24" href="/comprod/columns/mainthing/index.html">
<area coords="94,1,187,24" href="/comprod/columns/techvision/index.html">
<area coords="189,1,278,24" href="/comprod/columns/webstories/index.html">
<area coords="280,1,373,24" href="/comprod/columns/intranet/index.html">
<area coords="375,1,467,24" href="/comprod/columns/newsgroup/index.html">
</map>
The image (which specifies border=0 because back then the default behaviour
for graphical browser was to put a thick border around images within
hyperlinks) says usemap="#maintopmap" to cross-reference the <map> below it,
which defines rectangular areas on the image and where they link to, if you
click them! This ingenious and popular approach meant that you could transmit
a single image - saving on HTTP round-trips, which were relatively
time-consuming before widespread adoption of HTTP/1.1's persistent connections
- along with a little metadata to indicate which pixels linked to which pages.
The ismap attribute is provided as a fallback for browsers that didn't yet
support client-side image maps but did support server-side image maps: there
were a few! When you put ismap on an image within a hyperlink, then when the
image is clicked on the href has appended to it a query parameter of the form
?123,456, where those digits refer to the horizontal and vertical coordinates,
from the top-left, of the pixel that was clicked on! These could then be
decoded by the webserver via a .map file or handled by a CGI program.
Server-side image maps were sometimes used where client-side maps were
undesirable, e.g. when you want to record the actual coordinates picked in a
spot-the-ball competition or where you don't want to reveal in advance which
hotspot leads to what destination, but mostly they were just used as a
fallback. (Server-side imagemaps are enjoying a bit of a renaissance on .onion
services, whose visitors often keep JavaScript disabled, to make image-based
CAPTCHAs. Simply show the visitor an image and describe the bit you want them
to click on, e.g. "the blue pentagon with one side missing", then compare the
coordinates of the pixel they click on to the knowledge of the right answer.
Highly-inaccessible, of course, but innovative from a purely-technical
perspective.)
Both client-side and server-side image maps still function in every modern web
browser, but I've not seen them used in the wild for a long time, not least
because they're hard (maybe impossible?) to make accessible and they can't
cope with images being resized, but also because nowadays if you really wanted
to make an navigation "image" you'd probably cut it into a series of smaller
images and make each its own link.
Anyway, let's come back in October 1997 and see if they've fixed their
now-incomplete page:
(IMG) Screenshot from Netscape Columns: Web Site Stories: the Coming Soon page is now laid out in two columns, but the expected launch date has been removed.
Oh, they have! From the look of things, they've re-written the page from
scratch, replacing the version that got scrambled by that other employee.
They've swapped out the banner and menu for a new design, replaced the footer,
and now the content's laid out in a pair of columns.
There's still no reliable CSS, so you're not looking at columns: (no
implementations until 2014) nor at display: flex (2010) here. What you're
looking at is... a fixed-width <table> with a single row and three columns!
Yes: three - the middle column is only 10 pixels wide and provides the "gap"
between the two columns of text. (Nowadays, use of tables for layout - or,
indeed, for anything other than tabular data - is very-much frowned upon: it's
often bad for accessibility and responsive design. But back before we had the
features granted to us by the modern Web, it was literally the only way to get
content to appear side-by-side on a page, and designers got incredibly
creative about how they misused tables to lay out content, especially as
browsers became more-sophisticated and began to support cells that spanned
multiple rows or columns, tables "nested" within one another, and background
images.)
This wasn't Netscape's only option, though. Did you ever hear of the
<multicol> tag? It was the closest thing the early Web had to a
semantically-sound, progressively-enhanced multi-column layout! The author of
this page could have written this:
<multicol cols=2 gutter=10 width=301>
<p>
Want to create the best possible web site? Join us as we explore the newest
technologies, discover the coolest tricks, and learn the best secrets for
designing, building, and maintaining successful web sites.
</p>
<p>
Members of the Netscape web site team, recognized designers, and technical
experts will share their insights and experiences in Web Site Stories.
</p>
</multicol>
That would have given them the exact same effect, but with less code and it
would have degraded gracefully. Browsers ignore tags they don't understand, so
a browser without support for <multicol> would have simply rendered the two
paragraphs one after the other. Genius!
So why didn't they? Probably because <multicol> only ever worked in Netscape
Navigator.
Introduced in 1996 for version 3.0, this feature was absolutely characteristic
of the First Browser War. The two "superpowers", Netscape and Microsoft, both
engaged in unilateral changes to the HTML specification, adding new features
and launching them without announcement in order to try to get the upper hand
over the other. Both sides would often refuse to implement one-another's new
tags unless they were forced to by widespread adoption by page authors,
instead promoting their own competing mechanisms (It was a horrible time to be
a web developer: having to make hacky workarounds in order to make use of the
latest features but still support the widest array of browsers. But I'd still
take that over the horrors of rendering engine monoculture!).
Between adding this new language feature to their browser and writing this
page, Netscape's market share had fallen from around 80% to around 55%, and
most of their losses were picked up by IE. Using <multicol> would have made
their page look worse in Microsoft's hot up-and-coming browser, which wouldn't
have helped them persuade more people to download a copy of Navigator and
certainly wouldn't be a good image on a soon-to-launch (any day now!) page
about best-practice on the Web! So Netscape's authors opted for the dominant,
cross-platform solution on this page (Or maybe they didn't even think about it
and just copy-pasted from somewhere else on their site. I'm speculating.).
Anyway, let's fast-forward a bit and see this project finally leave its "under
construction" phase and launch!
(IMG) Screenshot showing the homepage of Netscape Columns from 15 February 1998; the first recorded copy NOT to have a header link to the Webstories / Web Site Stories page.
Oh. It's gone.
Sometime between October 1997 and February 1998 the long promised "Web Site
Stories" section of Netscape Columns quietly disappeared from the website.
Presumably, it never published a single article, instead remaining a perpetual
"Coming Soon" page right up until the day it was deleted.
I'm not sure if there's a better metaphor for Netscape's general demeanour in
1998 - the year in which they finally ceased to be the dominant market leader
in web browsers - than the quiet deletion of a page about how Netscape
customers are making the best of the Web. This page might not have been
important, or significant, or even completed, but its disappearance may
represent Netscape's refocus on trying to stay relevant in the face of
existential threat.
Of course, Microsoft won the First Browser War. They did so by pouring a
fortune's worth of developer effort into staying technologically one-step
ahead, refusing to adopt standards proposed by their rival, and their
unprecedented decision to give away their browser for free (This turned out to
be the master-stroke: not only did it partially-extricate Microsoft from their
agreement with Spyglass Inc., who licensed their browser engine to Microsoft
in exchange for a percentage of sales value, but once Microsoft started
bundling Internet Explorer with Windows it meant that virtually every computer
came with their browser factory-installed! This strategy kept Microsoft on top
until Firefox and Google Chrome kicked-off the Second Browser War in the early
2010s. But that's another story.).
LINKS
(DIR) My blog post from yesterday, Reflecting on Bloganuary
(HTM) My blog posts that contributed to Bloganuary 2024
(HTM) My blog stats page showing my streak of consecutive daily posts
(HTM) The WayBack Machine, from the Internet Archive
=> +3
(HTM) Håkon W Lie's original proposal for Cascading Style Sheets for HTML, written in 1994 and archived by the W3C
(HTM) Chuck Musciano's examination of JavaScript Style Sheets and how they differ from Cascading Style Sheets, written back when it was unclear which technology would come to dominate.
(HTM) My blog post, "20 Years of Blogging", published 2018
(HTM) TextFiles.com's collection of nearly a thousand "Under Construction" GIFs previously features on Geocities websites
(HTM) Cameron's World
(HTM) Mark Bernstein's article, "Hypertext Gardens: Delightful Vistas"
(HTM) GeeksforGeeks article about the isindex tag
(HTM) Line Mode Browser (LMB) on the World Wide Web Consortium site
(HTM) 2001 Computer World article describing the use of server-side includes
(HTM) MDN definition of framesets (which you shouldn't use, by the way)
(HTM) MDN description of client-side imagemaps
(HTM) MDN article about persistent connections
(HTM) Documentation by Friedrich-Alexander-Universität on the format of server-side imagemap configuration files
(HTM) Wikipedia article about Tor 'onion services'
(HTM) Tutorialspoint article about the multicol HTML tag
(HTM) CSS Tricks article by Rachel Nabors on the importance of browser diversity (which is very definitely under threat in the 2020s)