When you think of HTML and CSS, you probably imagine them as a package deal. But for years after Tim Berners-Lee first created the World Wide Web in 1989, there was no such thing as CSS. The original plan for the web offered no way to style a website at all.
There’s a now-infamous post buried in the archives of the WWW mailing list. It was written by Marc Andreessen in 1994, who would go on to co-create both the Mosaic and Netscape browsers. In the post, Andreessen remarked that because there was no way to style a website with HTML, the only thing he could tell web developers when asked about visual design was, “sorry you’re screwed.”
10 years later, CSS was on its way to full adoption by a newly enthused web community. *W**hat happened along the way?*
Finding a Styling Language
There were plenty of ideas for how the web could theoretically be laid out. However, it just was not a priority for Berners-Lee because his employers at CERN were mostly interested in the web as a digital directory of employees. Instead, we got a few competing languages for web page layout from developers across the community, most notably from Pei-Yaun Wei, Andreesen, and Håkon Wium Lie.
Take Pei-Yuan Wei, who created the graphical ViolaWWW Browser in 1991. He incorporated his own stylesheet language right into his browser, with the eventual goal of turning this language into an official standard for the web. It never quite got there, but it did provide some much-needed inspiration for other potential specifications.

In the meantime, Andreessen had taken a different approach in his own browser, Netscape Navigator. Instead of creating a decoupled language devoted to a website’s style, he simply extended HTML to include presentational, unstandardized HTML tags that could be used to design web pages. Unfortunately, it wasn’t long before web pages lost all semantic value and looked like this:
<MULTICOL COLS="3" GUTTER="25">
<P><FONT SIZE="4" COLOR="RED">This would be some font broken up into columns</FONT></P>
</MULTICOL>
Programmers were quick to realize that this kind of approach wouldn’t last long. There were plenty of ideas for alternatives. Like RRP, a stylesheet language that favored abbreviation and brevity, or PSL96 a language that actually allowed for functions and conditional statements. If you’re interested in what these languages looked like, Zach Bloom wrote an excellent deep dive into several competing proposals.
But the idea that grabbed everyone’s attention was first proposed by Håkon Wium Lie in October of 1994. It was called Cascading Style Sheets, or just CSS.
Why We Use CSS
CSS stood out because it was simple, especially compared to some of its earliest competitors.
window.margin.left = 2cm
font.family = times
h1.font.size = 24pt 30%
CSS is a declarative programming language. When we write CSS, we don’t tell the browser exactly how to render a page. Instead, we describe the rules for our HTML document one by one and let browsers handle the rendering. Keep in mind that the web was mostly being built by amateur programmers and ambitious hobbyists. CSS followed a predictable and perhaps more importantly, forgiving format and just about anyone could pick it up. That’s a feature, not a bug.
CSS was, however, unique in a singular way. It allowed for styles to cascade. It’s right there in the name. Cascading Style Sheets. The cascade means that styles can inherit and overwrite other styles that had previously been declared, following a fairly complicated hierarchy known as specificity. The breakthrough, though, was that it allowed for multiple stylesheets on the same page.
See that percentage value above? That’s actually a pretty important bit. Lie believed that both users and designers would define styles in separate stylesheets. The browser, then, could act as a sort of mediator between the two, and negotiate the differences to render a page. That percentage represents just how much ownership this stylesheet is taking for a property. The less ownership, the more likely it was to be overwritten by users. When Lie first demoed CSS, he even showed off a slider that allowed him to toggle between user-defined and developer-defined styles in the browser.
This was actually a pretty big debate in the early days of CSS. Some believed that developers should have complete control. Others that the user should be in control. In the end, the percentages were removed in favor of more clearly defined rules about which CSS definitions would overwrite others. Anyway, that’s why we have specificity.
Shortly after Lie published his original proposal, he found a partner in Bert Bos. Bos had created the Argo browser, and in the process, his own stylesheet language, pieces of which eventually made its way into CSS. The two began working out a more detailed specification, eventually turning to the newly created HTML working group at the W3C for help.
It took a few years, but by the end of 1996, the above example had changed.
html {
margin-left: 2cm;
font-family: "Times", serif;
}
h1 {
font-size: 24px;
}
CSS had arrived.
The Trouble with Browsers
While CSS was still just a draft, Netscape had pressed on with presentational HTML elements like multicol
, layer
, and the dreaded blink
tag. Internet Explorer, on the other hand, had taken to incorporating some of CSS piecemeal. But their support was spotty and, at times, incorrect. Which means that by the early aughts, after five years of CSS as an official recommendation, there were still no browsers with full CSS support.
That came from kind of a strange place.
When Tantek Çelik joined Internet Explorer for Macintosh in 1997, his team was pretty small. A year later, he was made the lead developer of the rendering engine at the same as his team was cut in half. Most of the focus for Microsoft (for obvious reasons) was on the Windows version of Internet Explorer, and the Macintosh team was mostly left to their own devices. So Starting with the development of version 5 in 2000, Çelik and his team decided to put their focus where no one else was, CSS support.

It would take the team two years to finish version 5. During this time, Çelik spoke frequently with members of the W3C and web designers using their browser. As each piece slid into place, the IE-for-Mac team verified on all fronts that they were getting things just right. Finally, in March of 2002, they shipped Internet Explorer 5 for Macintosh. The first browser with full CSS Level 1 support.
Doctype Switching
But remember, the Windows version of Internet Explorer had added CSS to their browser with more than a few bugs and a screwy box model, which describes the way elements are calculated and then rendered. Internet Explorer included attributes like border and padding inside the total width and height of an element. But IE5 for Mac, and the official CSS specification called for these values to be added to the width and height. If you ever played around with box-sizing
you know exactly the difference.
Çelik knew that in order to make CSS work, these differences would need to be reconciled. His solution came after a conversation with standards-advocate Todd Fahrner. It’s called doctype switching, and it works like this.
We all know doctypes. They go at the very top of our HTML documents.
<!DOCTYPE html>
But in the old days, they looked like this:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
That’s an example of a standards-compliant doctype. The //W3C//DTD HTML 4.0//EN
is the crucial bit. When a web designer added this to their page the browser would know to render the page in “standards mode,” and CSS would match the specification. If the doctype was missing, or an out of date one was in use, the browser would switch to “quirks mode” and render things according to the old box model and with old bugs intact. Some designers even intentionally opted to put their site into quirks mode in order to get back the older (and incorrect) box model.

Eric Meyer, sometimes referred to as the godfather of CSS, has gone on record and said doctype switching saved CSS. He’s probably right. We would still be using browsers packed with old CSS bugs if it weren’t for that one, simple trick.
The Box Model Hack
There was one last thing to figure out. Doctype switching worked fine in modern browsers on older websites, but the box model was still unreliable in older browsers (particularly Internet Explorer) for newer websites. Enter the Box Model Hack, a clever trick from Çelik that took advantage of a little-used CSS attribute called voice-family
to trick browsers and allow for multiple widths and heights in the same class. Çelik instructed authors to put their old box model width first, then close the tag in a small hack with voice-family
, followed by their new box model width. Sort of like this:
div.content {
width: 400px;
voice-family: ""}"";
voice-family: inherit;
width: 300px;
}
Voice-family was not recognized in older browsers, but it did accept a string as its definition. So by adding an extra }
older browsers would simply close the CSS rule before ever getting to that second width. It was simple and effective and let a lot of designers start experimenting with new standards quickly.
The Pioneers of Standards-Based Design
Internet Explorer 6 was released in 2001. It would eventually become a major thorn in the side of web developers everywhere, but it actually shipped with some pretty impressive CSS and standards support. Not to mention its market share hovering around 80%.
The stage was set, the pieces were in place. CSS was ready for production. Now people just needed to use it.
In the 10 years that the web hurtled towards ubiquity without a coherent or standard styling language, it’s not like designers had simply stopped designing. Not at all. Instead, they relied on a backlog of browser hacks, table-based layouts, and embedded Flash files to add some style when HTML couldn’t. Standards-compliant, CSS-based design was new territory. What the web needed was some pioneers to hack a path forward.
What they got was two major redesigns just a few months apart. The first from Wired followed soon after by ESPN.
Douglas Bowman was in charge of the web design team for Wired magazine. In 2002, Bowman and his team looked around and saw that no major sites were using CSS in their designs. Bowman felt almost an obligation to a web community that looked to Wired for examples of best practices to redesign their site using the latest, standards-compliant HTML and CSS. He pushed his team to tear everything down and redesign it from scratch. In September of 2002, they pulled it off and launched their redesign. The site even validated.

ESPN released their site just a few months later, using many of the same techniques on an even larger scale. These sites took a major bet on CSS, a technology that some thought might not even last. But it paid off in a major way. If you pulled aside any of the developers that worked on these redesigns, they would give you a laundry list of major benefits. More performant, faster design changes, easier to share, and above all, good for the web. Wired even did daily color changes in the beginning.

Dig through the code of these redesigns, and you’d be sure to find some hacks. The web still only lived on a few different monitor sizes, so you may notice that both sites used a combination of fixed width columns and relative and absolute positioning to slot a grid into place. Images were used in place of text. But these sites laid the groundwork for what would come next.
CSS Zen Garden and the Semantic Web
The following year, in 2003, Jeffrey Zeldman published his book Designing with Web Standards, which became a sort of handbook for web designers looking to switch to standards-based design. It kicked off a legacy of CSS techniques and tricks that helped web designers imagine what CSS could do. A year later, Dave Shea launched the CSS Zen Garden, which encouraged designers to take a basic HTML page and lay it out differently using just CSS. The site became a showcase of the latest tips and tricks, and went a long way towards convincing folks it was time for standards.
Slowly but surely, the momentum built. CSS advanced, and added new attributes. Browsers actually raced to implement the latest standards, and designers and developers added new tricks to their repertoire. And eventually, CSS became the norm. Like it had been there all along.
Enjoy learning about web history? Jay Hoffmann has a weekly newsletter called The History of the Web you can sign up for here.
The good old days.
Thanks for nice article. It was so nice remember old good days. IE6 was the most awful browser of all times. In CSS we were needed to write a lot of hacks and conditional comments like this:
<!--[if IE 6]>
Yet another hack for IE6.
<![endif]-->
:) Thanks once more.
I wonder how close you could get to designing a modern web page layout with only CSS Level 1?
Would be a great challenge!
Browser support is a key in CSS implementation.
By the end of the 90’s, IE5 was taking the lead over Netscape4. And Netscape 6 came out with a breaking change, supporting already a lot of CSS and way better, but so differently, it was not widely adopted and IE6 buried it. But Netscape didn’t completely died… the phoenix came back through Mozilla 1.0, using the open source code of Netscape.
Eventually Firefox came out of it as well and advocated so much for standard that IE6 became the official ugly duckling. And Safari, and Chrome…
We used to struggle with 2 or 3 resolution (640×480, 800×600, 1024×768; these were for desktop you younglings!). Then with ways to handle JS between IE and Netscape (remember
document.all
vsdocument.layers
?)Then with CSS inconsistencies (double-margin bug, IE hacks…).
Now we just have 250 screen resolutions. Piece of cake!
http://csszengarden.com/
This site completely altered my outlook on html structure, CSS and design in general. I learned to take a very close to stock HTML structure and turn it into almost any layout. It really opened my eyes to what CSS could do for web designers and developers.
I hope the react css-in-js nuts don’t wreck future web standards that created the beauty in simplicity that is modern CSS. I am all for doing what needs to get done, but we got here for a reason.
A bit of memory lane here, ty. (not missing the old days of design, that is for sure)
I don’t think the margin has never been included inside the total width and height of an element. It was the border, not the margin that was part of the box’s dimensions (width/height).
Good stuff. But you omitted The Web Standards Project, without which none of this would’ve happened. Tantek and Eric did what they did as participants in WaSP-led initiatives. A List Apart’s promotion of WaSP values to designers and developers and early use of CSS layout inspired what Doug and Mike did at Wired and ESPN, respectively. Dozens of WaSP members and thousands of eventual supporters drove this movement. Their contributions deserve to be remembered.
Thanks for reading, and thanks for pointing that out!
I didn’t include it in this post, but you are absolutely right that it would have fit. WaSP is an organization I find myself coming back to over and over again in the newsletter I send out every week, though I’ve never had a chance to tell the full history of WaSP, and it’s incredible influence over the web’s trajectory, something I most certainly want to do. If you ever had some time, I would love to quickly chat with you about what it was like joining and leading WaSP so that I can make sure I have everything right. Either way, I definitely want to tell that story and I hope that when I do, I do the project and its members, who I agree we owe an enormous debt of gratitude and need to be remembered, justice.
And it’s not over yet! IE still has its annoying quirks and is going strong!
Are you sure IE isn’t mostly dead? I can’t think of a good reason to support anything lower than IE 10 (only because of windows 7), and it’s not super horrible with CSS anymore.
Randing from 3.5% – 14.8%
https://en.wikipedia.org/wiki/Usage_share_of_web_browsers
There’s a note that says theses are the “non-mobile” list, so this cuts these values in real world terms in more than half. So the actual percentage of IE use on the net is more like 1.5% – 7%, being very generous.
And considering these are worldwider numbers, and many designers focus on the businesses in their own countries (US for my company), this makes this number even less relevant.
The final nail in the IE coffin is that MS doesn’t even support IE anymore. And if a client says their site doesn’t look good/correct in their browser, I point out the security implications of using unsupported browser and they upgrade and the problem goes away.
Last but not least, if a client wants to support IE, I simply provide an estimate of costs to support it, with a known percentage of users with IE, and 100% of the time, they decline to pay for IE support.
Vanderson, how about the UK’s National Health Service – the fifth largest employer in the world. I.E. 7 rules the roost there…
Choice and Common Sense
First off, I let my clients decide, and they pay for the support. Can’t give away a potentially large percentage of the cost of project for free.
Second, know your market and users. I am in the US, and most of my clients are businesses, small to medium (I tend not to want to work with huge companies anymore, as they drain the life out of you) and they don’t have any site visitors (existing sites with stats) that use IE 7 anymore. So it’s completely a non-issue there. (or if they do, it’s so small it’s not worth it for them to pay for the support… again, their choice)
Last, it hits a point where you just have to move on. IE 6 hung around a really long time. And despite it’s solid percent of users, I (and I bet everyone else here) had to just cut support and let IE 6 users see a messy site.
Even you are deciding right now to cut support for something. Where is the line? How do you choose where the cutoff line is? Factor in all the data you can, and make an educated, common sense choice.
Also, I propose that there is a massive difference in development standards when you build for only 1 website, vs hundreds or even thousands of websites. (especially if it’s a government or huge corp website)
Security
2006 is when IE 7 was released.
Timeline of browser history
How many people here support Safari 2 or Firefox 1.5, Netscape 8.1 or Opera 9? Chrome didn’t even exist for another 2 years, iOS and Android did not exist for another year or more. But throw in the first versions of all mobile browsers to this list then. (including the Android browser)
I’d surmise you don’t support any these browsers.
To make matters worse, by supporting IE 7 (actually anything lower than IE 11), you are actively promoting the use of an insecure browser (insecure for over a year and half now!)
Having things look bad in IE 7 is a GOOD thing. It is the smallest thing we can do as designers (short of an actual message) to help people realize they are using an insecure browser.
I think it’s our duty as webdesigners to instantly stop all support for any and all browsers that no longer receive security updates from their developers.
How can you in good conscience knowingly make a site look correct in a browser that is pretty much guaranteed to hurt the user?
Again, that is 1 and 1/2 years of insecure IE 7, and who knows about the others… The only version of IE that is getting security updates is version 11.
https://www.microsoft.com/en-us/windowsforbusiness/end-of-ie-support
Boy, I feel old. Looking at those websites it looks like it´s millions of years away. Styling with images, tables everywhere, “3D” buttons and all those colors …
I was being paid for designing web sites before CSS was a thing.
Man, I’m old AF.
I think the value of the Acid2 (and later Acid3) tests in giving us a consistent CSS experience should not be overlooked. In a simple page it gave the web standard developers a tool to demonstrate how the standard should be implemented and browser developers used it, among others, as a point of pride and contention when touting CSS support. Without it and similar tests, we would still be in the world where the ambiguities in the wording of the specification let implementors choose which way to implement certain rules based on what was convenient for them, rather than what would be convenient to the web designers and users.