I started designing websites from around the age of 12. That would have been the early 2000s, so while it wasn't the very early days of the web it was still a nightmare to build anything that looked good and would work cross-browser.
The main difficulty back then wasn't the design, but all the random tricks and hacks you'd have to learn before you could do anything that looked impressive and worked reliably. And I don't think I'm exaggerating when I say it took years to get good at.
But since I had just been doing this for fun since I was a kid I didn't really appreciate how difficult it was until I got to university and found myself trying to explain things to people who had never used CSS and HTML before.
Being a good web developer in the 2000s basically meant becoming an encyclopedia of random CSS and browser bugs. Half the time there was no logic in what you did, just pure brute force memorisation of cross-browser weirdness, CSS compatibility tables and JS hacks.
Things are better now, but I do miss those times. The simplest things were challenging back then.
To me, even more impressive than displaying the website in a 1993 browser is the fact that you can even compile xmosaic for a modern linux OS with only minor tweaks. Reminds me of a couple recent HN thread about Wayland and X11, and GTK4. Will we be able to compile today's applications 30 years into the future. Probably not even in five.
(Tangentially Related): There's a subreddit that measure's "how timeless" a song is based on terms/idioms used in the lyrics and checking the etymology of said terms.
It then ranks how far back in time you could transport the song based on when those terms were in use, or if there are readily swappable analogs for them.
Considering nearly every deprecated element still works in modern browsers, you could just make your website for 1994 browsers.
You'd have to keep the layout pretty simple, and the font size would be too small due to lower resolutions back then, but modern browsers can zoom so it's practically a non-issue.
Font size in web browsers was never defined in actual display pixels. Text on a 1994 website will look fine in today's browsers because it will use the browser's default style sheet (probably 16px Times for body text).
If readability is truly your pursuit, then it is my humble opinion that you should avoid high contrast white/lightgrey on pitch black colors when designing a dark theme for your app or website, or consider adding a toggle to switch to a light theme. I gave up at the end of the first section of this article because it was just too much.
Hi, author here. What was too much? Are you talking about my colourscheme, or my writing? I've actually been trying out different colourschemes for my site lately, and I'm genuinely open to suggestions. I actually took the contrast into account when picking colours, and consciously lowered the overall contrast by saturating the text and background colour a little. I don't think the contrast is much higher than many other dark-themed sites I look at often, like Github for example. I'm sorry you didn't enjoy it either way.
No your writing is fine, and sorry if I'm being a negative nancy. It's just that light text on black backgrounds cause me eye strain so they're not really my cup of tea. The light grey font color does help a litte though. I often experience lines of text being burned into my vision with these themes, and that effect was not as noticeable here.
I am admittedly not a fan of dark themes in general, but I feel they are done right when the dark background is toned down a bit so you're not staring at a pitch black screen. And not just by a few shades.
As an aside, I didn't even know GitHub had a dark theme. I just tried it and it was horrible. Then I switched from dark default to dark dimmed and it was much more tolerable, although I still prefer light.
That's okay, I really appreciate the feedback! I'll give this some thought and see if I can tweak the colours a little. I often find myself falling back on Firefox's 'Reader View' if I find a website's colour theme a bit too jarring.
I've never heard this term 'text measure' before. Do you mean the number of characters per-line in the main content column? I tried to research the optimal column width, but the answers seem to vary so much. Just doing a quick search online right now: This source[1] says 55-100, which is a pretty big range. Although this source[2] claims that research suggests that "Reading speed was highest at 95cpl, and lowest at 35cpl on screen".
I'll take your suggestion on-board at any rate, and might make some adjustments to the font-size, or cpl. Thanks for your help!
Yep, that's the one. It depends on how many curveballs you're throwing at the user. I'm working on a monospace library that looks wide at 48 characters per line.
That's what the inverted text is here, a curveball. It's not the problem itself but it is asking more of the user every line. Just eyeballing it, .blog-entry looks correct, at least text measure wise, with a max-width of 500px.
At 13.5:1, the contrast ratio on your site (#D8DAD7/#0F100F) is a bit much. With a background of #444444 the ratio would be 6.92:1, just shy of a AAA result.
I don't think you're out of date rather the parent is conflating WCAG saying "don't have contrast less than" as if it meant "your contrast should be near".
Ah, that is definitely true and I agree with your conclusion about it. I think these two replies were specifically in response to the "At 13.5:1, the contrast ratio on your site (#D8DAD7/#0F100F) is a bit much" portion though, it read as if 13.5:1 was too much contrast instead of just more than the minimum. Sorry for misinterpreting that bit!
Interesting to see another opinion. I love #FFF on #000 and I hate those low-contrast off-white + off-black "dark" themes like they are on codeberg and forgejo. Bonus trigger points if they have some color mixed in, e.g., #D4D4D8 on #171E26. I was always wondering why would anyone would do that.
In the last sample "everything was wrong" because "CSS was not invented for the next three years". Was pure html styling not an option? It's still what is done in html emails for compatibility I believe?
Unfortunately Mosaic didn't support much in the way of layout elements. The <table> element wouldn't even be added to the HTML standard until May 1996, in RFC 1942. These were the earliest days of HTML, and things were still very, very basic!
My thoughts exactly! It's probably painful for a web developer from today to put the styling into the HTML files, use tables for layout, and all the other "good old" hacks, but I think he could have gotten reasonably close to the design even in an ancient browser. With a lot of effort, of course...
I think the earliest you can reproduce the layout is probably somewhere around 1997, which was when HTML4 was standardised. Earlier than that the block model was really primitive, and didn't support things like arbitrary margins and padding. Mosaic didn't even support arbitrary block elements like <div>. From 1993 to 1998 things were developing really rapidly, with the state of the art advancing so much each year. It must have been a really exciting time to be involved!
> “It must have been a really exciting time to be involved!”
It seems kind of hard to believe today, but most of the excitement in 1995-98 was around Java applets.
To a lot of people it seemed that the interesting interactive stuff would be delivered in Java, and HTML was just a basic document format that was destined to become primarily an export target for tools like Frontpage or Word.
Browser vendors were adding junk features like the <blink> and <marquee> tags, which didn’t improve the perception that Java is a real platform while HTML is ad hoc document glue.
In the olden days you used 1x1px transparent gifs for margins. You could also use table cell spacing and padding if you were going all out on tables.
Another common hack was a fixed width table with a text-align=right attribute inside a single center tag. This gave you a fixed width content area (inside the table) that was centered in case the user's window was wider than your design's intended width.
As far as an exciting time, the state of the art advancing was great but there were a lot of limitations. HTML and browsers rapidly advanced but people didn't necessarily jump on those updates. There was also a lot of divergence between the specs and implementations. Reliable layouts targeted the lowest common denominators between different browsers.
A useful hack if you want to support very old browsers is to link your external CSS via @include inside HTML comments. Pardon errors, coffee hasn't kicked in yet:
Old IE and Navigator versions that would try to load your CSS will ignore the CSS inside the comments. If you add text and background color attributes on the <body> tag you'll even be able to maintain colors on old browsers.
So long as your unstyled layout is sane, old browsers will display a useful rendition of your page. Or at the very least not completely broken.
This same hack can be used to hide JavaScript from old browsers. It also works if you're inlining CSS.
I'd forgotten about that. I could search for the answer but I think it's more fun to talk about it: how did that work? Wouldn't that make all browsers ignore the includes?
HTML comments are not valid CSS. But no one told old IE and Navigator versions this important fact. It's for the best because they didn't really handle CSS all that well. If they encountered 2.x properties they'd often lose their shit and mess up the whole layout from spite.
Eventually both caught on and interpreted everything in the <style> tag as the declared language and thus ignored the inappropriate HTML comment tags. At the same time their CSS handling also improved so they'd break less badly when actually encountering CSS.
Kids, you have no idea how much better we have it now!
Back then, there wasn't a reasonable reliable cross-browser way to get single pixel collapsed table borders. If you wanted to have such a thing, you'd need to nest the table inside another table with a single cell for the background color. But Netscape had awful table rendering performance. The more content in the table, the longer Netscape would take to sit there and render it, scaling disproportionately. The nesting just made it worse! This was also in the days before reflow. If you resize the viewport, Netscape would redraw the entire page from scratch!
It would have saved the decade where tables were the 'bad' way to layout a webpage, but you had to figure out how to do with different combinations of block and inline block.
Oh my god. That just fired a neuron in my brain that hasn't been active in almost 30 years I think. I literally forgot I programmed with that at one point!
This was a fun read (well, at least if your definition of “fun” is “brings back painful memories”). Maybe I overlooked it but I didn’t see any rationale for which browsers to include. Did Chrome render it perfectly in 2008? How did Safari do in 2003?
Is there a collection of Linux virtual machine images I could use to run old browsers (say from 1994)? There's https://infinitemac.org/ for MacOS and Windows 3/95/98 VMs, but I've had a hard time getting Linux binaries from the early 90s working.
you gave me flashbacks of trying to get random software i heard about to compile for redhat and debian linux back in the very late 90s or early 2000s. I reckon, if ordered to, i could probably get a system with source available to run decades-old software. As it stands my oldest working OS is Ubuntu 6.04. If you know of an archive of freshmeat or whatever, it might be possible to get something like this working in about a week of tinkering. oh dependency hell, what a time we had together
edit: my oldest on the metal OS. VMs i didn't count.
The main difficulty back then wasn't the design, but all the random tricks and hacks you'd have to learn before you could do anything that looked impressive and worked reliably. And I don't think I'm exaggerating when I say it took years to get good at.
But since I had just been doing this for fun since I was a kid I didn't really appreciate how difficult it was until I got to university and found myself trying to explain things to people who had never used CSS and HTML before.
Being a good web developer in the 2000s basically meant becoming an encyclopedia of random CSS and browser bugs. Half the time there was no logic in what you did, just pure brute force memorisation of cross-browser weirdness, CSS compatibility tables and JS hacks.
Things are better now, but I do miss those times. The simplest things were challenging back then.