Welcome back to Deep Dive. We are back with another
stack of research. And today we are looking at
something that is simultaneously the most boring
and maybe the most fascinating string of characters
on the entire internet. It is certainly the most
ubiquitous. I'll give you that. Absolutely. We
are talking about the very first line of code
on essentially every single web page you have
ever visited. Yeah. You right click, you hit
view source, and before you get to the content,
before the scripts, before any of the styles,
there's this declaration. Usually it's just docu
-type HTML. The document type declaration. Right.
And, you know, looking through the materials
we have today, the specs, the history, the browser
notes, I was just struck by this central paradox.
We talk all the time about code efficiency. Right.
We talk about minification, compressing images,
shaving off every possible millisecond of load
time. Oh, yeah. Every byte counts. Every byte
counts. And yet the entire web is built on shipping
this one specific tag that, according to the
modern spec itself, is mostly useless but required.
It's a wonderful contradiction, isn't it? I mean,
it really frames the whole discussion perfectly.
It does. We are essentially shipping billions
of bytes of data across the globe. every single
day that technically do nothing, at least not
in terms of processing content. But if you take
them away, the whole thing falls apart. The visual
web just completely falls apart. And that's what
I want to get to the bottom of today. Because
usually in engineering, if something is useless,
you deprecate it. You get rid of it. You delete
it. Of course. But here, we're keeping it. It
feels, I don't know, it feels like a ritual.
It's like we're lighting a candle before we start
coding just to appease the gods of the internet
or something. That's surprisingly close to the
truth, actually. DOSI type is a fossil. A fossil.
It's a remnant of a completely different era
of computing history, the SGML era, that has
survived into the modern web purely as a switch.
It's just a signaling mechanism. Okay. So the
mission for this deep dive is to figure out why.
We're going to unpack the syntax, which I learned
is actually way, way more complex than just that
simple HTML5 tag. We're going to look at the
history of sniffing, which I have to say sounds
a little illicit, but it's actually just browser
logic. And we have to talk about quirks mode.
We are definitely going to talk about quirks
mode. And I really want to understand. why modern
browsers have decided to just completely ignore
the sophisticated maps that were provided in
the older code. It's a journey. It's a journey
from the very strict academic world of standardized
markup to the, well, to the messy, pragmatic
reality of the web we actually built. Okay, let's
start at the beginning then, section one. What
is a doxy type? If we strip away all the modern
context and just look at the definition and the
source material, what are we actually looking
at here? To understand the doxy type, you really
have to understand that the web wasn't invented
in a vacuum. It was born out of this whole world
of document processing that already existed.
Right. Specifically, it came from something called
SGML, the Standard Generalized Markup Language.
SGML. This is like the grandfather of HTML. Correct.
SGML was a massive, incredibly complex international
standard for defining document structures. It
wasn't really a language itself. It was a metal
language. What does that mean, a metal language?
It was a language for creating other languages.
And in that world, you couldn't just write...
tags willy -nilly. You couldn't just make things
up. You had to define your terms first. So you
couldn't just invent a pizza tag unless you had
first defined what a pizza tag was and what it
could contain. Exactly. You needed a rule book.
And that rule book is called the document type
definition. The DDD. The DDD is a file that says,
okay, in this language, we have an element called
pizza. It can contain cheese and sauce, but it
absolutely cannot contain rocks. it lays out
the entire grammar okay so the dtd is the law
the dtd is the law and the dock heat The document
type declaration is the instruction inside your
actual document that links it to that law. Ah,
I see. It's a way of telling the computer, hey,
I'm about to send you some data. Before you try
to read it, please go refer to this specific
rulebook so you know how to interpret everything.
It's like declaring the rules of the game before
you deal the cards. We're playing poker, so use
the poker rulebook. Precisely. And in the serialized
form, which just means the actual text file you
send over the wire, this instruction has to come
first. It has to be right at the top. which is
why we see it as that short string of markup
at the very top of the file. Now, one thing the
nodes highlight is this concept of the root element.
The doc type doesn't just point to a file. It
also defines the root. What's that about? This
is a really critical Parsewell concept. In SGML
and its descendant, XML, a document is a tree
structure. Right, like a family tree. Exactly.
And every tree has to have a single trunk from
which everything else branches off. The parser,
the program reading the file, needs to know what
that trunk is before it starts so it knows where
to begin building the tree. So for a web page,
that root is almost always HTML. Usually, yes.
But in the abstract world of SGML, it could be
anything. you could have a doci type where the
root element is library or memo. But for the
web, the doci type effectively says two things.
I am declaring that this document adheres to
the HTML D2D and the root element of this tree
is HTML. So it's telling the parser, okay, get
ready. Expect an HTML tag to start this whole
thing off. Exactly. And this is important. The
doci type then applies those rules to everything
descending from that root. The whole tree. The
entire tree. Once you declare the root, every
single branch and leaf inside it is subject to
the rules of that DTD you referenced. Okay, so
that's the theory. In a perfect world, or at
least, you know, in the academic world of the
1990s, the browser would see this docu -type,
it would go look up the rules in the DGD, and
then it would validate your code against those
rules. And if you broke a rule, the computer
would throw an error and say, nope. not valid
that was the dream of something called prescriptive
markup the idea was that if we all enforce these
really strict rules machines could easily read
any document without any ambiguity but we know
the web's not unambiguous the web is a complete
mess the web is a beautiful beautiful mess so
let's move to section two then the browser's
secret decision because this is really where
the theory just collides head -on with reality
right This is where it gets interesting. So I
asked myself this question when I was reading
the notes. What happens if I mess this up? Let's
say I'm a web developer in 1999. I forget the
Dothie type PE or make a typo in it. Does the
browser just stop working? Crash? Well, if the
browser stopped working every time a developer
made a typo, the Internet would have died in
1996. Fair point. The browser makers, you know,
Netscape and Microsoft. In the thick of the browser
wars, they faced this huge dilemma. They wanted
to implement new standards. They wanted to support
CSS correctly. They wanted to fix all the bugs
in their rendering engines. Sure, they wanted
to move forward. But millions of websites had
already been built, and they were built relying
on the old buggy behavior. If they just fixed
the browser, all those old sites would shatter.
Layouts would break. Text would overlap everywhere.
It would have been a complete disaster. The web
would have become unusable overnight. So they
couldn't just update the engine. They had to
somehow support the bad code and the good code
at the same time. Enter Doctype Sniffing and
Switching. Sniffing. Hmm. It sounds so investigative
like a detective. It is, in a way. When a browser
receives a document that's served as text TML,
it doesn't just blindly start rendering it. It
looks at that very first line, the Doctype -y,
and it sniffs it. Sniffs it. It checks it against
an internal list of known patterns to decide
which rendering mode it should use. It's making
a judgment call based on that one line. And this
is where we get the two main modes, right? Right.
Quirks mode and standards mode. There's actually
a third one called almost standards mode, which
is a whole other rabbit hole. But yeah, let's
stick to the big two for clarity. They're the
most important. Okay, let's talk about Quirks
Mode. The name itself implies it's just a little
bit weird, but the source material suggests it's
actually a highly sophisticated emulation of
failure. That is a great way to put it. Quirks
Mode is a compatibility layer. If the docketype
is missing entirely, or if it's an old, malformed
docketype that suggests the author didn't know
about modern standards. So if it looks like it
was written in 1998. Exactly. The browser enters
Quirks Mode. And in this mode, the browser deliberately
intentionally violates the modern web specifications
to mimic the behavior of old browsers like Internet
Explorer 5 or NetState 4. Can we get specific
here? The notes mention something called the
box model. This seems to be the biggest, most
famous difference between the modes. This is
the classic example. It's the one everyone points
to. So imagine you have a box on your screen.
A div, let's say. Okay. And you write some CSS.
You say its width is 100 pixels and you add 10
pixels of padding on each side. All right. 100
pixels wide, 10 pixels of padding. Got it. In
the W3C standards, the correct way, which is
what standards mode uses, the width property
refers only to the content area. Okay. There
have 100 pixels of content plus 10 pixels of
padding on the left plus 10 pixels of padding
on the right. What's the total visible width
of the box? 120 pixels. 100 plus 10 plus 10.
Correct. That makes logical sense. That's standards
mode. But in the old Internet Explorer, they
did it differently. How so? They said, if I declare
the width as 100, the whole darn box should be
100 pixels wide, period. So they squished the
content. The padding was included inside that
100 pixel width. The content area would only
be 80 pixels. Oh, I see. So if I built a whole
website. relying on my boxes being exactly 100
pixels wide to fit next to each other. And then
suddenly the browser updates and starts following
the standard. Your box is now 120 pixels wide.
And my entire layout breaks. My sidebar probably
falls down to the bottom of the page. The whole
site looks ruined. And your boss is yelling at
you. So quirks mode tells the modern browser,
even the latest version of Chrome or Firefox
running today, to use that old mathematically
incorrect calculation for whip. It preserves
the quirk. Exactly. But if you provide a correct
modern Docky type, the browser says, aha, this
author knows what they're doing. They want to
follow the specs. And it switches to standards
mode using the correct box model. So the DocsTag
really is just a switch. But, yeah. Here's the
dirty secret that really blew my mind in the
research. We talked about how the doc type is
supposed to point to a DTD file, right? A URL.
Yes, that's the theory. So logic would suggest
the browser would download that file from the
URL to check the rules. But the sources say that
modern browsers have these special purpose HTML
parsers that do not use general purpose DTD logic
at all. This is the big twist. Modern browsers.
Chrome, Safari, Edge, Firefox, do not download
the DTD. They never look at the file. Never.
If you put a URL in your doc type pointing to,
you know, http .www .w3 .org something .dtd,
the browser completely ignores that URL. It does
not make a network request. It does not fetch
it. It does not read it. So why is it even there?
In the modern context, it is there purely for
the string matching algorithm. That's it. The
browser has a hard -coded internal list of strings.
A list of patterns. Exactly. It just says, if
the characters at the very top of this file match
this specific sequence, turn on standards mode.
If they don't, or if there's nothing there, turn
on quirks mode. So it's not reading the map.
It's just checking to see if you have a map in
your hand. That's a great way to put it. It's
pure pattern recognition. The browser developers
essentially said, Parsing TTDs is slow, it's
complex, and it's completely unnecessary because
we already know what HTML is. They just baked
the rules for HTML directly into the browser's
C++ or Rust code, rather than having to read
them from some external text file every time.
That is fascinating. It really means that Dossi
Typee is strictly a trigger. It's not data. It's
just a button. It's a button disguised as data.
So if we're just poking a button, let's look
at what that button actually looked like. Because
before HTML5 came along, we weren't just typing
HTML. We were typing these massive, complex incantations.
Oh, the syntax was a beast. It was something
else. Let's move to section three then. Anatomy
of the syntax. I really want to deep dive into
those characters because I feel like I typed
them for 10 years without ever actually reading
or understanding them. All right, let's decode
the cipher. Okay, looking at the source here.
The general syntax for a docket type. In the
old STML style, it opens with docu -type. I want
to note the exclamation point. It feels like
it's shouting. It's a declaration. In markup
languages, that exclamation point usually signals,
hey, this isn't an instruction for the parser.
This is not an element to be displayed on the
page. Okay, that makes sense. Then we have the
root element, which we've established is usually
each PML. Right. But then we get these keywords.
public or system, and then these really long
strings in quotes. Let's break down system first
because that one seems a little simpler. System
is the straightforward one. If you see the keyword
system. It is followed by what's called a system
identifier. In the context of XML and the web,
this is almost always a URI, a uniform resource
identifier, basically a URL. So system just means,
hey, browser, the rules, the DTD, it's located
at this specific address. Go get them. Exactly.
It points directly to a file on a disk or on
a server. Very literal. But we rarely use system
on its own, did we? We almost always use public.
What does public mean in this context? Public
is a bit more abstract. It indicates that the
DTD is a public text. A public text. Yeah. It
means this isn't just some random file on my
personal server. This is a shared well -known
standard that should be known to the system already.
So it's like a celebrity file. In a way, yeah.
It points to a public identifier. This is just
a unique name for that standard. It's kind of
like saying the U .S. Constitution. You don't
need to tell me the physical address of the piece
of paper in the National Archives. The name itself
identifies the document. And this leads to that
really specific weird string we always saw. The
FPI, the formal public identifier. I want to
parse this string. Natchez W3CTD XHTML 1 .1EN.
I used to stare at those slashes and just wonder
what they meant. It looks like total nonsense,
but it's actually a very strict, very formal
cataloging syntax. Okay, let's break it down.
What is the minus sign at the very beginning?
So that minus sign indicates the registration
status of the identifier. A plus sign plus would
mean it's an officially registered ISO standard.
A minus sign means it is unregistered. Wait,
hold on a second. The standard for the World
Wide Web from the W3C is marked as unregistered.
In the very strict formal sense of ISO SGML registration,
yes. It basically just means we are an important
organization, but we are not the international
organization for standardization. So it starts
with a minus. That is a fantastic piece of trivia.
The entire web is built on unregistered documents.
Pretty much. Then you have the double slash R.
That's just the delimiter, a separator. Then
W3C, that part is the owner identifier. It tells
you who maintains this public text. Okay, that
makes sense. W3C, the World Wide Web Consortium.
Then another delimiter and DTD. XHTML 1 .1. That
is the public text class in the description.
It tells you what kind of document it is, a DTD,
and which version it is, XHTML 1 .1. And finally,
the EN at the end. That's the language, English.
So it's like a Dewey decimal system for code.
It's saying, unregistered, owned by W3C. It's
a DTD for XHTML 1 .1, and it's in English. Exactly.
And the original idea was that a parser would
have a catalog, like a lookup table, built right
into it. It would see the string, look it up
in its internal table, and the table would say,
oh, I have a local copy of that DTD right here
on the hard drive. I don't need to go out to
the internet to find it. But also, looking at
the old syntax, right after that long public
identifier string, there was also a URL in quotes.
Why both? That's the fallback. That's the backup
plan. If you use public, you provide the official
name, but just in case the parser doesn't have
that name in its catalog, you also provide the
system identifier, the URL, as a backup. So it's
like saying, here's the name of the book I want.
If you don't have it in stock, here is the address
of the library where you can go find it. That's
a perfect analogy. And in XML, this was very
strict. If you use public, you had to provide
the system identifier URI as well. You couldn't
just leave it hanging. Now, there's one more
part of this syntax that this source material
calls a hidden feature, the internal subset.
The part with the square brackets. Ah, yes. This
is the part that the power users really loved.
Where does this even go? I don't think I've ever
seen it. It goes at the very end of the dossy
type declaration, just before the final closing
angle bracket. And what goes inside those brackets?
Actual DPD rules. You could define entities or
even change element rules in line right there
inside your HTML file. So I could, in theory,
rewrite the rules of HTML from within the document
itself. To an extent, yes. The internal subset
is processed first. It has the highest precedence.
So if you defined an entity inside those brackets,
it would override whatever was defined in the
external DTD file. Can you give me an example?
I mean, why would I ever use this? Well, back
in the old days, you might use it to define a
shortcut. For instance, you could define an entity
called nleg to mean written by the legal department.
Copyright 1999. Then anywhere in your document
where you typed in leg, the parser would automatically
expand it to that full phrase. It was like a
variable, a macro. Exactly. Or you could use
it to temporarily disable certain validation
rules if you were testing something or had a
special case. It was very powerful in the proper
SGML world. But again, let me bring it back to
modern browsers. You know the answer. Chrome
ignores it. Firefox ignores it. The browser's
HTML parser is not a real SGML parser. It doesn't
process entities defined in the internal subset.
It just sees the brackets and skips right over
them. It's a vestigial organ. It's like the appendix
of the syntax. That's exactly what it is. It's
there because the grammar says it's allowed to
be there. But functionally, for the purpose of
rendering a web page, it does absolutely nothing.
Okay, so we've got the syntax. Now let's look
at the flavors. Because this wasn't just about
syntax. It was about... I don't know, philosophy.
In the HTML 4 .01 era, we had to make a choice
every single time we started a new file. The
clan wars. The DTD wars. Section 4. The flavors
of HTML. The notes list three really distinct
DTDs for HTML 4 .01. Strict, transitional, and
frameset. Let's talk about strict. This one always
felt like it was on the moral high ground. It
absolutely was. HTML 4 .01 strict was the W3C
basically saying this is how the web should be.
The key characteristic of the strict DTD is that
it did not allow any presentational markup. And
presentational markup means things that control
how the page looks rather than what the content
means. Right. No font tags, no center tags, no
BG color attributes on your table cells. The
argument was all about separation of concerns.
HTML is for structure and semantics. CSS is for
presentation. Which is. I mean, that's the standard
best practice we all follow today. It is now.
But back then, CSS support in browsers was spotty,
to be generous. Right. Internet Explorer 4 and
Netscape 4 were just terrible at CSS. So if you
were brave and used the strip DTD, you were often
fighting against the browser to get even basic
layouts to look right. It was a real pain. So
they gave us an out. They gave us the transitional
DTD. also known as loose. The transitional DTD
was a diplomatic compromise. It was the W3C saying,
okay, we really want you to use CSS, but we acknowledge
that you probably still need to use a font tag
here and there or an align center attribute just
to get this page to work for your client. So
it was the, we know you're trying, but we accept
your flaws, DTD. It was the bridge from the old
way to the new way. It allowed all those deprecated
presentational elements. And interestingly, almost
everyone used transitional. It became the de
facto standard because strict was just too painful.
And the third one, very quickly, frameset. Ah,
frames. A dark time. For our younger listeners,
can we just briefly explain what a frame even
was? Sure. Before we had good server -side includes
or modern JavaScript frameworks, if you wanted
a navigation bar that didn't reload every time
you clicked a link, you used frames. You would
essentially split the browser window itself into
independent subwindows. Like a grid of little
browser windows. Exactly. One window for the
menu, one for the header, one for the main content.
But it was a usability nightmare. Oh, it was
terrible. It completely broke the URL bar. The
address in the browser wouldn't change as you
navigated inside the frames. It broke bookmarks.
It broke the back button. But if you used it,
you needed a special DTD, the frameset DTV, which
basically told the browser, hey, this page doesn't
have a body tag. It has a frameset tag instead.
OK, so that was HTML 4 .01. But then came the
era of XHTML, the X standing for XML. This was
the absolute peak of the strict philosophy. The
W3C decided that HTML is just too messy, too
forgiving. They wanted to reformulate HTML as
a... Proper XML application. Which meant it had
to follow all the strict syntax rules of XML.
All of them. Case sensitivity became a big deal.
In regular HTML, tag and tag are the same thing.
In XML, they are completely different. And XML
requires lowercase tags. Right. And you must
close every single tag no, leaving a p tag open
just because you started a new one. You have
to write pp, and you have to put quotes around
all your attribute values. No more with 100.
It has to be with 100. And the DTDs for XHTML,
they just mirrored the HTML one. For XHTML 1
.0, yes. You had XHTML 1 .0 strict, transitional,
and frameset. But because it was XML, the syntax
requirements were even tighter. For example,
as we mentioned earlier, you had to include the
system identifier, the URL, and the doc .tp.
No inferring allowed. And then came XHTML 1 .1,
the final form. This was supposed to be the finalized
revision. It was the purest form. It dropped
the transitional and frameset options entirely.
It was strict or nothing. It was designed to
be modular. It was beautiful from a pure computer
science perspective. And it was a complete disaster
in reality. It failed spectacularly because of
something called draconian error handling, which
is a core principle of XML. Draconian error handling.
Yes. In true XML, if you have a single syntax
error, a missing quote, an unclosed tag, anything,
the parser is required to stop. It's supposed
to show an error message. The yellow screen of
death. The famous yellow screen of death in Firefox.
It doesn't try to guess what you meant. It just
stops and refuses to render the page at all.
And you just can't have a web where a single
missing quotation mark takes down the entire
New York Times homepage. Exactly. The robustness
principle. Be conservative in what you send.
Be liberal in what you accept. That's what won
out. Browsers continue to accept messy HTML,
and the strict XHTML revolution largely happened
in name only. Most developers who thought they
were writing XHTML were actually serving it as
text HTML, so the browsers were just treating
it as tag soup anyway. Which brings us finally
to the resolution of our story. The Great Pragmatism
of HTML5. Section 5. The Simplification. We went
from these massive intimidating strings, docs
.html public, docket .w3c, dt .html 1 .0 transitional,
and http .www .w3 .org. I have to assume that
in HTML5, we just simplified the DTD. We didn't
just simplify it. We obliterated the entire concept
of the DTD. So what is the modern syntax? It's
docket .ptml. What's it? That's the whole thing.
Case insensitive, usually. No URL. No public
identifier. No FPI. Nothing. Why? Why is it so
short? Because HTML5 is not defined by SGML,
it's its own standard with its own parsing rules.
It doesn't need to reference an external rulebook
because the rules are defined in the HTML spec
itself, which the browsers then implement natively
in their code. So it's an independent language
now. It's all grown up and left home. Correct.
But here's the kicker. The spec still says the
Doctomail is required. So why is it required
if it doesn't even point to a DTD anymore? Solely
for the switch. The only reason Docty type HTML
exists is to satisfy that sniffing algorithm
we talked about back in section two. So it's
just to trigger standards mode. That is its one
and only purpose. It is the shortest possible
string of characters that triggers standards
mode in Internet Explorer 6 and all of its successors.
It's a password. It's the minimum viable Docty.
The browser developers basically got together
and asked, what is the absolute least amount
of text we can force developers to type that
will still convince our old legacy code that
this is a modern page? And the answer was dock
to pipe HTML. That is hilarious. It's like wearing
a tie to a Zoom meeting, but you're still wearing
pajama pants just out of frame. You just need
to show the tie, the dock type to get into the
meeting. which is standards mode. That is a perfect
description of what's happening. It looks like
an old SGML declaration. It has the exclamation
point. It has the doxy type E word, but it's
completely hollow. There's no DTD behind it.
It's a facade for legacy compatibility. Now,
you mentioned case sensitivity. In HTML5, it's
insensitive. So I can write doc, doc type in
all lowercase. It's fine. In a regular HTML document
served as text TML, yes. But if you are writing
XHTML5, which is the XML serialization of HTML5,
then you are back in XML land. And the strict
rules apply again. They do. XML is case sensitive.
The root element HTML must be lowercase. Therefore,
the doxy type decoration must match that. You
have to write doxy type eHTML, all lowercase.
And the notes also. mentioned that in XHTML5
the doxy tag is actually optional. Theoretically
yes, because a true XML parser doesn't have a
quirks mode in the same way an HTML parser does,
so it doesn't need the switch. However, the source
mentions an important edge case. polyglot document.
A document that's written to be valid as both
HTML and XML simultaneously. If you want your
file to be readable by a strict XML parser and
render correctly in a regular web browser as
HTML, you absolutely need the doc type to keep
the browser in standards mode. So, just keep
it in. Just keep it in. It's 15 characters. It
saves you a potential world of pain. It really
is a fascinating evolution when you lay it all
out. Yeah. We started with this incredibly high
-minded, academic, structure, public catalogs,
system identifiers, internal subsets. We literally
built a bureaucracy of code. And then the messy
market realities of the browser wars just came
in and smashed that bureaucracy to pieces. And
what we're left with today is a fossil. A tiny
15 -character scar at the top of every single
file that just reminds us of this massive battle
between purism and pragmatism. And it's the ultimate
victory of pragmatism. The standard now officially
admits that the docs type is mostly useless.
I mean, that's a refreshing level of honesty
for a technical specification. So to summarize
our investigation today, we learned that the
docs type is technically an instruction to associate
a document with a DTD. But in reality, for modern
web pages, it is just a behavioral trigger. And
we learned that sniffing is the browser's way
of deciding whether it should emulate the bugs
of the 1990s, which is quirks mode, or follow
the rules of today, which is standards mode.
We learned that the URL in all those old doctypes
was essentially a lie. or at least a suggestion
that was universally ignored by the actual browsers
who rely on internal pattern matching instead.
And we decoded the entire bureaucracy of the
FBI, the owner, the class, the language, only
to realize that the modern web has thrown all
of it away for the simple, elegant docu -type
HTML. It's just a great lesson in how standards
actually evolve in the real world. They don't
move in these perfect straight lines, they meander,
they break, and sometimes they just leave these
weird little artifacts behind. It reminds us
that code is written by humans for systems that
have a history. We can't just delete the past.
We have to build these compatibility layers on
top of it forever. Which leads me to a final
thought I want to leave with you, the listener.
Let's hear it. We've established that the modern
web is built on a polite fiction. We include
a line of code that looks like a definition,
but it's actually just a trigger. The browser
ignores the data and just looks at the shape
of the tag. Yes, that's right. So if the docker
ANSI type, the very first line of the web, is
essentially a ritual we perform purely to appease
legacy code from the days of Internet Explorer
6. What else are we doing? That is the question.
How many other best practices that we follow
in our modern stacks, in JavaScript, in our CSS,
in our server configurations, are actually just
rituals, things we do because that's how it's
always been done or because it used to fix a
bug in a browser from 2015 that doesn't even
exist anymore? We're basically coding by superstition.
We're afraid to remove the talisman because we
don't remember exactly what demon it was originally
designed to keep away. The Doctype is the ultimate
talisman. And as long as browsers have that quirks
mode lurking inside them, we have to keep wearing
it. And honestly, considering the alternative
is broken layouts everywhere and the return of
the box model hack, I am more than happy to type
those 15 characters. Me too. Long live the doxie
typhee. Thank you for joining us on this deep
dive into the invisible history of the web. Always
a pleasure to debug the past with you. Check
your source code, everyone. We'll see you on
the next deep dive.