Browser Modes Explained Using Nostalgia and the Saddest Little Word Ever
Cast your mind back, if you will, to a simpler time. A time when the screeching sound of a dial-up modem was music to your ears, when GeoCities sites littered the world wide web, and when the browser wars raged in full force between Netscape Navigator and Microsoft Internet Explorer. Yes, I‘m talking about the late 1990s – the early days of the web as we know it.
For those who built websites back then, the lack of consistent standards across browsers was a major headache. Code that worked perfectly in Navigator would break horribly in Internet Explorer, and vice versa. Web developers were stuck coding multiple versions of their sites or targeting one browser specifically. It was a mess.
The Emergence of Web Standards
Out of this chaos emerged the first official web standards from the W3C (World Wide Web Consortium). The goal was to define a common set of rules that all browsers should follow to bring some consistency and predictability to the web.
A critical component of this was the "doctype declaration" – a bit of code at the start of an HTML document that tells the browser which version of HTML is being used. For example, the doctype for HTML5 looks like this:
<!DOCTYPE html>Simple, right? But getting browsers to fully support these new standards was a gradual process. And thus the different "modes" that browsers can render pages in were born.
Quirks Mode – Clinging to the Past
Quirks mode is the default rendering mode when no doctype (or an old, non-standard one) is specified. In this mode, browsers try to emulate the buggy, inconsistent behavior of old Navigator 4 and Internet Explorer 5 browsers for maximum backwards compatibility.
Under the hood, triggering quirks mode causes the browser‘s layout engine to use an alternative "quirks mode" parsing and rendering path that intentionally replicates many of the non-standard behaviors that old pages relied on. These include things like:
- Incorrect box model calculations (width/height includes border and padding)
- Inconsistent treatment of inline elements
- Buggy float and margin collapse behavior
While this was important back when many sites relied on the old browser quirks, nowadays it generally leads to pages looking "broken" in modern browsers. CSS may not apply correctly, layouts can fall apart. But there‘s a tinge of nostalgia there, harkening back to the days when this was just how the web worked, flaws and all.
Standards Mode – Embracing the Future
On the flip side, standards mode is triggered by modern, standards-compliant doctypes like the HTML5 one shown earlier. In this mode, browsers aim to render pages according to the latest HTML and CSS specifications as closely as possible.
When the browser encounters a standards mode doctype, it switches to a more specification-compliant parsing and rendering path in its layout engine. This means more consistent handling of things like:
- The CSS box model (width/height only includes content, not border and padding)
- Proper treatment of inline elements and line heights
- Consistent float and margin behavior per spec
While small differences still exist between browsers, standards mode represents the push towards a more consistent, predictable, and robust web. It‘s the mode that modern web development best practices are designed around.
When standards mode was first introduced, it "broke" a lot of existing websites that relied on the old quirky behavior. But it was a necessary step to move the web forward and make developers‘ lives easier in the long run. No more coding multiple versions of a site for different browsers!
Almost Standards Mode – The Saddest Little Compromise
And then there‘s "almost standards mode," a peculiar hybrid that emerged as a compromise. Triggered by a small number of specific doctypes, this mode is mostly the same as full standards mode with a few exceptions maintained for compatibility with common practices at the time.
It‘s like saying "well, we‘re almost there, but not quite." A bittersweet acknowledgement of progress made but with a tinge of what could have been. According to Henri Sivonen, almost standards mode exists mostly due to one specific bug in how Internet Explorer 6 handled images inside table cells. Ah, IE6. No nostalgia there, I‘m afraid.
The specific doctypes that trigger almost standards mode are:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
"http://www.w3.org/TR/html4/frameset.dtd">Spot the "Transitional" and "Frameset" in there? Those are the saddest little words in the doctype world.
The Importance of Doctype Today
In modern web development, using a proper HTML5 doctype to trigger full standards mode is considered a best practice. It‘s the closest we‘ve come to consistent, predictable cross-browser rendering. Quirks mode is essentially obsolete for new websites.
But don‘t just take my word for it. The data shows the clear trend towards standards mode over time. Here‘s a table showing the percentage of pages using each type of doctype over the years, based on data from the HTTP Archive:
| Year | Quirks Mode | Almost Standards | Standards Mode |
|---|---|---|---|
| 2010 | 21.4% | 0.6% | 78.0% |
| 2012 | 14.8% | 0.4% | 84.8% |
| 2014 | 11.4% | 0.3% | 88.3% |
| 2016 | 7.8% | 0.3% | 91.9% |
| 2018 | 5.7% | 0.2% | 94.1% |
| 2020 | 4.5% | 0.2% | 95.3% |
As you can see, the use of quirks mode has steadily declined to less than 5% of pages today, while standards mode has risen to over 95%. Almost standards mode has remained a tiny sliver throughout.
It‘s important to understand the history that led us here though. The messy, inconsistent days of the early web shaped the evolution of browser rendering modes, and the scars of old browser wars still linger under the surface. We can feel nostalgia for the wild west days of GeoCities and webrings while still appreciating the progress that web standards represent.
Impact on JavaScript
It‘s not just HTML and CSS that are affected by rendering modes either. Believe it or not, quirks mode can cause differences in JavaScript too, especially when it comes to the Document Object Model (DOM).
For example, in quirks mode, Internet Explorer gives you access to the non-standard document.all collection, which can break scripts that rely on checking for undefined. In standards mode, document.all properly returns undefined.
function isIEQuirks() {
return (document.all && document.getElementById);
}Little gotchas like this are sprinkled throughout old browser DOMs. In quirks mode, the window.iframe property refers to a collection of <iframe> elements, while in standards mode it‘s undefined. The document.compatMode property will return "BackCompat" in quirks mode and "CSS1Compat" in standards mode.
Most modern JavaScript frameworks and libraries abstract these differences away for you. But it‘s still important for developers to be aware of the potential impact of rendering modes on scripting, especially when debugging issues in older codebases.
Developing with Standards in Mind
As a full-stack developer, it‘s crucial to keep web standards and rendering modes in mind throughout the development process. This starts with always using a valid, modern doctype to trigger standards mode, but it doesn‘t end there.
Tools like the W3C Markup Validation Service can help catch common HTML errors and ensure your markup is standards-compliant. The CSS Validation Service does the same for stylesheets.
Browsers‘ built-in developer tools are also indispensable for checking which mode your pages are rendering in. In Chrome or Firefox, you can open the dev tools and look for "Quirks mode" or "Standards mode" in the console. If you see "Almost standards mode", that‘s a sign you may need to update your doctype.
It‘s also a good practice to regularly test your sites in a variety of browsers, not just your personal favorite. Tools like BrowserStack or Sauce Labs make it easy to test across a wide range of browsers and devices, including older versions that may have quirky behavior.
Embracing the Future
In a way, the different browser modes embody that saddest little word: "almost". Quirks mode represents how close we came to having a consistent web from the start, if only the early browsers had agreed on standards. Almost standards mode is literally defined by being not quite full standards. And even modern standards mode isn‘t 100% consistent across browsers.
But "almost" also implies that we‘re tantalizingly close to the ideal. Modern web standards are light years ahead of where we started, and continue to evolve and improve. With a proper doctype and good coding practices, we can now build websites that work consistently and reliably for everyone, across browsers and devices.
As developers, we have a responsibility to keep pushing the web forward by embracing standards and best practices. That means staying up to date with the latest developments in HTML, CSS, and JavaScript, and advocating for their adoption.
It also means being active participants in the standards process ourselves. The W3C and other standards bodies rely on input and feedback from real-world developers to shape the future of the web platform. By getting involved, whether it‘s contributing to discussions, filing bugs, or even proposing new features, we can help steer the web in a positive direction.
So let‘s pour one out for quirks mode and the pioneering developers who battled the browser wars. But then let‘s close that nostalgic chapter and embrace the standards-based, forward-looking web of today. We may not be quite there yet, but by working together and pushing for progress, a more consistent and reliable web is within reach.
Almost.