Historical System ArchivesHistorical System ArchivesA curated repository of historical system documents, obsolete web specifications, and legacy software design notes preserved for research by Binary & Bus, Sys. The materials below are reconstructed from primary sources, terminal session logs, and archived specification drafts.
The following is a reconstructed excerpt from the NeXTSTEP Human Interface Guidelines, documenting the original constraints that shaped early workstation interface design. These rules established patterns that persist in modern desktop environments.
NeXTSTEP Human Interface Guidelines - Section 3.2
"Window Management and Screen Layout"
Reconstructed from archived documentation, 1989.
3.2.1 Display Constraints
The NeXT Display PostScript system renders at 72 DPI
on the standard MegaPixel Display (1120x832 usable).
All interface dimensions must be specified in points,
where 1 point = 1 pixel at 72 DPI.
Minimum touch target size: 24x24 points.
Minimum text height: 12 points (9pt body + 3pt leading).
Maximum window width: 1120 points (full screen).
Recommended content width: 560 points (half screen).
3.2.2 Font Specifications
The system provides the following typefaces:
- Helvetica (sans-serif, proportional)
- Courier (monospace, fixed-width)
- Times (serif, proportional)
- Symbol (symbolic characters)
Default menu font: Helvetica 12pt.
Default title font: Helvetica-Bold 14pt.
Default monospace: Courier 12pt.
3.2.3 Colour Palette
The MegaPixel Display supports greyscale only.
Interface elements must be designed for 4-bit (16
levels) or 8-bit (256 levels) greyscale rendering.
Background: white (255).
Text: black (0).
Disabled text: 50% grey (128).
Selection highlight: inverted (black background).
Terminal session capture documenting the behaviour of early HTML parsing in the Mosaic 2.0 and Netscape 1.1 browsers. Reconstructed from archived newsgroup posts and specification discussions on the www-talk mailing list.
SESSION LOG: html-parse-test-1995-03-14.txt Source: Reconstructed from www-talk mailing list archives. Date: 14 March 1995 $ ./mosaic --dump http://www.w3.org/MarkUp/html-spec.html | head -40HyperText Markup Language Specification 2.0 HyperText Markup Language Specification 2.0
NOTES: 1. The HTML 2.0 specification (RFC 1866) defines the baseline DTD for HTML documents. All conforming browsers MUST accept documents using elements and attributes defined in this DTD. 2. The DOCTYPE declaration is informational only. Browsers do NOT use it to select a parsing mode. Instead, parsing behaviour is determined by the content of the document itself. 3. Character encoding defaults to ISO-8859-1 (Latin-1) when no Content-Type header or META charset is specified. This was the universal default until UTF-8 adoption in the late 1990s. 4. The TITLE element is mandatory. Browsers that encounter a document without a title display the URL or an empty title bar. BENCHMARK: Mosaic 2.0 on SPARCstation 10 28.8 kbps modem connection HTML 2.0 document (4 KB): 1.4s to first paint HTML 2.0 document (12 KB): 3.2s to first paint Image (JPEG 50 KB): 17.8s to complete
Performance measurement logs comparing modem connection speeds against early broadband connections. These benchmarks establish baseline latency figures that inform our current TCP payload budget.
LOG FILE: dialup-benchmarks-1997-08-20.txt
Source: Lab measurements, Binary & Bus Systems test bench.
Hardware: Pentium MMX 200MHz, 32MB RAM, US Robotics 33.6k modem.
TEST 1: 28.8 kbps V.34 Modem
Connection speed: 28,800 bps (actual: 27,200 bps after overhead)
DNS resolution: 340 ms average
TCP handshake: 180 ms average (to dial-up POP)
HTTP GET 4 KB document:
Time to first byte: 420 ms
Time to first paint: 1,840 ms
Total transfer: 2,100 ms
HTTP GET 14.6 KB document:
Time to first byte: 420 ms
Time to first paint: 5,680 ms
Total transfer: 6,200 ms
HTTP GET 50 KB document (with images):
Time to first byte: 420 ms
Time to first paint: 19,400 ms
Total transfer: 21,100 ms
TEST 2: 56 kbps V.90 Modem
Connection speed: 56,000 bps (actual: 48,000 bps typical)
DNS resolution: 280 ms average
TCP handshake: 150 ms average
HTTP GET 4 KB document:
Time to first byte: 340 ms
Time to first paint: 1,200 ms
Total transfer: 1,400 ms
HTTP GET 14.6 KB document:
Time to first byte: 340 ms
Time to first paint: 3,200 ms
Total transfer: 3,600 ms
TEST 3: 128 kbps ISDN BRI
Connection speed: 128,000 bps (2x64k bonded)
DNS resolution: 180 ms average
TCP handshake: 80 ms average
HTTP GET 14.6 KB document:
Time to first byte: 120 ms
Time to first paint: 1,040 ms
Total transfer: 1,200 ms
CONCLUSION:
A 14.6 KB document fits within the TCP slow-start
congestion window on all tested connections, requiring
only a single RTT for the initial burst. Documents
exceeding this budget trigger additional round trips,
each adding 200-600 ms depending on connection type.
At 28.8 kbps, every additional kilobyte costs ~68 ms
of transfer time. Keeping total page weight under
15 KB is the single most impactful optimisation for
dial-up and constrained mobile connections.
Cross-browser rendering test results documenting how HTML 3.2 documents were parsed and displayed across the major browsers of the mid-1990s.
LOG FILE: browser-comparison-1996-11-02.txt Source: Lab measurements, Binary & Bus Systems test bench. Test document: 8 KB HTML 3.2 with 3 inline images (total 22 KB) BROWSER RENDER TIME CORRECT LAYOUT IMAGE LOAD --------------------------------------------------------------- Netscape Navigator 3.0 1,420 ms Yes Sequential Microsoft IE 3.0 1,680 ms Yes Parallel Arena 0.99 2,100 ms Partial* Sequential Lynx 2.5 (text-only) 340 ms N/A N/A Links 0.8 (text-only) 280 ms N/A N/A * Arena 0.99 did not fully support the TABLE element with COLSPAN attributes. Tables rendered as linear lists of cells. KEY FINDINGS: 1. Text-only browsers (Lynx, Links) render HTML 3.2 documents 4-5x faster than graphical browsers by eliminating image decoding and layout computation. 2. Parallel image loading in IE 3.0 provided a measurable advantage for pages with multiple inline images, but the benefit diminishes above 6 images due to connection concurrency limits. 3. All browsers correctly parsed HTML 3.2 heading elements (H1-H6), paragraph elements, and unordered lists without any CSS assistance. 4. The total rendered output was visually consistent across Netscape and IE, confirming that HTML 3.2 provides a reliable baseline for cross-platform document delivery without authoring custom browser hacks.
Navigation & Lab Index: