HTML and how Nuclear Research Led to the Web

HTML is one of the fundamental building blocks of the modern web as we know it today. But what is HTML really?

We’re going to dive into the history of Markup Languages and the web and try to get a real understanding of something that seems so simple, yet powers so much of the world. Nearly every website on the web uses HTML to display everything from your simple recipe website to banking apps. Many people love the simplicity of HTML and modern web development libraries and frameworks such as React, Svelte, and HTMX put it at the forefront of their design. Is it a programming language? How was it created? What is it really?

If you have ever asked any of these questions then this is the podcast for you. Let’s get started.

To begin let’s breakdown the name:

Hypertext Markup Language.

Let’s start at the beginning.

Hypertext

What is the hypertext?

Hypertext is just the idea that a document can be linked to other documents through “hyperlinks”.

Lets take the example of a book about dogs. In traditional print, if you were reading a book about dogs you would read it from front to back. Often times you may come across a word that is unfamiliar or requires further explanation. In these cases, there is a glossary at the back of the book that will explain the term. Let’s say you come across the word Daschsund but you don’t know what it is. The book may direct you to the glossary where it informs you that a dachshund is also known as a wiener dog and may even display a picture.

Using “Hypertext” we can take this idea one step further. No longer are you limited by the physical space of a book. So, in theory, if you come across the unfamiliar term “Dachshund” in a “Hypertext” document. You can use a “hyperlink” to take you to a whole different document that contains everything you could possibly want to know about dachshunds.

So hypertext can link to other hypertext documents, creating an amazing way to share information easily.

Now, What is markup?

Markup

Markup is essentially a term used in print editing. The author would write the document and then an editor would “Mark Up” the text for the printer so that the printer would know how the document should be formatted.

Markup for a Toronto Star article

For example, to indicate whether a section of a sentence would be in italics, they would write “I-T-A-L” on the page above the specified section. They could denote whether something should be bolded or whether it should be surround by quotation marks.

On a fundamental level, this is what the “Markup” in Hypertext Markup Language is. Electronic Markup telling the computer what to display. In the case of HTML it is actually better defined as a descriptive markup language: something that labels the document parts semantically as opposed to how aspects of the page should be processed.

So a markup language labels the parts of a document.

History of Markup Languages

Charles Goldfarb (one of the creators of GML) poses with the XML handbook

We now have kind of a working definition for Hypertext Markup Language. Something that labels the text semantically and links to other pages. But that isn’t exactly all that it does. And to understand this, we’re going to learn a bit about the history of Markup Languages. Starting all the way back in 1969 with Generalized Markup Language. Or GML.

GML was created, in the late 1960s and early 1970s by The father of markup languages Charles Goldfarb, as well as Edward Mosher and Raymond Lorie. They had created the language to display large complicated documents in a format that would be easy to read on computers.

While they had an idea for the goal of the language they hadn’t quite thought about what they would name it. So, in an effort to lend a part of themselves to the language, they decided to use the initials of their last names (Goldfarb, Mosher, and Lorie) as an initialism: GML.

The syntax for GML is fairly similar to modern html in that you would open a tag and then write the content after it. Each tag (for example, an h2 tag) would be preceded by a colon.

This was incredibly useful for displaying documents but it ended up being difficult to standardize so,

Nearly 17 years later, in 1986, Standardized General Markup Language or SGML was released. SGML was built to display a variety of different documents on a computer but also have more standardization in terms of how it is written. The common syntax was as follows: you could create an opening tag with an opening bracket followed by a letter or word followed by a closing bracket. But it really depended on the DTD, or the Document Type Declaration. A DTD is a specification file that contains what is allowed within the document.

A sample SGML document

A DTD defined element types that represented structures or desired behavior. For an SGML application, a company or government agency would develop an SGML DTD, declaring names and constraints for document elements and their attributes.

For example, would paragraph tags be allowed? Would you be able to leave ending tags off? Creators of the DTD could even indicate that they would like their tags to use something other than angle brackets. @ signs perhaps or really anything that was defined.

Some people really loved this and found it great to work with and others seemed to dislike many aspects of the language. Often DTDs would become incredibly large and difficult to work with. They would just build and build and developers would have to work with these absolutely massive DTDs that they would have to constantly reference.

In essence, it’s adaptability made it valuable for diverse applications, but this flexibility often led to unwieldy DTDs, posing challenges for developers who had to navigate these intricate specifications.

History of HTML

Sir Tim Berners-Lee with a computer

But a few years later, in 1989, Tim Berners Lee (later Sir Tim Berners-Lee) was working on an idea based on Ted Nelson’s theory of Hypertext. Tim had often collaborated with other researchers across the world while working at CERN and really wanted an easier way to share documents and collaborate more effectively. So he formulated an idea.

This idea was actually based on something that he had worked on in 1980, nearly ten years earlier called ENQUIRE. ENQUIRE had something similar to a page called a card and each of the cards had hyperlinks to other cards. One of the issues was that a new card would always have to be linked to a previous card.

Imagine it like this. Let’s say you are studying for a test and you are using flash cards to do it. All of these flash cards would be related so you create the first card, write down the topic, let’s say “Computers”, and then the description. In the description, it mentions Apple Computers and Microsoft. So you create new cards for Apple Computers and Microsoft and connect them to the first card with string. Now when you read about computers you can follow the string connected to Apple Computers and read more about it.

And so on from there. But what if you wanted to make a card about the fruit, oranges? Using Enquire, it would have to be connected to a previous card. But it doesn’t actually make sense logically to connect it.

This is a lot simpler than it was in reality, but I think it makes it easier to understand the issue.

Tim’s new idea would be a little bit different. It was to be a “Web” (like a spider web) of linked hypertext documents across the world. No longer would pages have to be linked to a previously existing page.

It would also build upon some amazing innovations in technology at the time.

The existing Internet Protocol (or IP) that handled the way data was dealt with. How it was packetized, addressed, transmitted, routed, and received over the network. It’s a little bit out of the scope of the podcast to address all of these but just know that using an IP address to connect with another computer would come to be extremely important.

It would also be built upon the Domain Name System created in the 80s. With DNS, users could connect to an ip address by using a human readable name.

Instead of typing 123.456.7.89 users could just remember a name like, say, google.com, and they would be connected to the correct location. Easy!

A server computer would host a page and others could type in the address to view it. But, it would need a brand new language to display the content.

So, as an application of SGML, Tim proposed Hypertext Markup Language. HTML. It was to be very easy to implement and fairly flexible. At the time, it contained only about 20 tags that could be used. It also had the ability to leave off ending tags. Something that saved space and potentially made it easier to write.

A developer could write an opening paragraph tag, put the text in and just leave the rest of the document blank and it would automatically be filled in later on. Something that it is still possible to do in HTML, although I don’t personally recommend it for a number of reasons.

Tim coded all of this on a NeXt computer (the computer created by Steve Jobs after he was ousted from Apple) and created the first browser to be able to display HTML. He even set up the first Web Server software to host this. It was a computer with a sticky note on it that said “This machine is a server. DO NOT TURN IT OFF!” Written in red ink.

A NeXt computer with a note that says "This machine is a server. Do not turn off."

I guess at CERN they had people that went around at night shutting off all the computers that people had left on. I can’t imagine walking in and shutting off a computer and becoming the guy that literally shut down the entire World Wide Web.

Anyways, at that moment the World Wide Web had its first server with its first website. And that website was about what else? The World Wide Web.

It was a website with a homepage that consisted of a header with several paragraphs of text describing the world wide web and linking to other locations such as definitions for hypermedia, help regarding the browser you are using, and technical details.

The first sentence is “The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents”.

You can actually still visit this website today at info.cern.ch although it is pretty much what you expect it to be. A bunch of text with hyperlinks to other pages. Pretty much the first thing any aspiring web developer creates when they learn HTML today.

There were actually several drafts as to what HTML would be. Some included features like tables and forms but there was never actually an official release of HTML 1.0. The first “official” version would be HTML 2.0 and it was so named so that people could differentiate it from the previous drafts and ideas for HTML. This was created in 1995 by the Internet Engineering Task Force.

Around this time, web browsers like Netscape Navigator and Internet Explorer were released and world wide web users could access websites on computers all over the world. No longer was there a single web server with a single website. By 1995 there were roughly twenty thousand websites and nearly 75000 web servers.

This was fantastic. Information could be disseminated across the world and anyone with access to a computer could access this information on the web. Additionally, other innovations were happening all over the web. A website called Auction House would launch that year where users could bid on products that they wanted to buy. It would eventually be renamed, to eBay. Websites like Craigslist, GameFAQs, Newgrounds, Yahoo search, MSN, and more would launch that year. All powered by the World Wide Web and HTML.

But there was a problem. If a person were writing HTML, they couldn’t really be sure how it would be displayed on a browser. Each web browser began to implement their own features that would only work on those specific browsers.

What’s more, they didn’t even display the same content in the same way. The default font may be completely different, sizing for different headings would be completely different, even spacing could potentially differ based on the browser you were using. This did not lead to a seamless experience for users OR for developers.

For these reasons, nearly a year earlier, Tim Berners Lee had formed the Worldwide Web Consortium (W3c). The idea was to standardize the web and allow for this seamless experience across the world. They didn’t (and still don’t) technically enforce anything but they do provide recommendations for what should be used and how. By 1996 they had published the first standards for CSS, allowing users to customize the appearance of their HTML.

Around this time, there was also a growing tension within the development community surrounding the standards of HTML. Some developers felt that it had strayed too far from its origins of SGML. There was no specification that users could look to as a guidebook and it was not strict enough. Developers would certainly develop bad habits leaving end tags off and the case insensitivity was just insufferable. It needed to be standardized and it needed to be stricter. At least, that was the thought of some.

So out of HTML came the the stricter specification of Extensible Markup Language (XML). If you are a developer today you may be familiar with an AJAX request or Ansynchronous Javascript and XML request. XML is a subset of SGML and is much stricter than HTML. Although it did not replace it.

Over the years attempts at creating a stricter standard for HTML would come and go. XHTML 1.0 would be released adding in error messages and stricter development. but overall it didn’t seem to appeal to most people. They really enjoyed the simplicity of HTML.

So HTML 3.0 and eventually 4.0 were published and they added support for audio, video, CSS, and javascript. Really leading to a whole renaissance of web development. But it was still just an application of SGML.

Around 2007, however, the W3C and another organization, WHATWG, began drafting HTML5. It would come with an official recommendation in 2014 but it added some great features. For one, it was no longer an application of SGML although it still included something that looked very similar to a Document Type Declaration. That little !DOCTYPE HTML that is added at the top of most HTML files actually triggers a standards compliant rendering mode. In other words, it tells the browser that the page is HTML5 and should be displayed according to the standards.

HTML5 also added a ton of new semantic features like nav, header, footer, and article, features for improved accessibility and more. Including a number of APIs that are specified and not specified.

From this point on, the history gets pretty convoluted. There are so many different working groups dictating what is going on and there are some disputes between W3C and WHATWG but it kind of concludes in W3C Ceding control over to WHATWG.

Basically, W3C had been trying to shift the standard towards things like XHTML and they were taking a really long time to make decisions and WHATWG didn’t like that.

So, as of 2019 to the current date, WHATWG is in control of HTML standards although they work in collaboration with W3C.

So there it is. A history of HTML. This is by no means a complete history and we certainly glossed over a ton of content but I hope this helps to elaborate on the formation of HTML and why we use it.

The hypertext links to other pages and the markup labels parts of the document semantically. Browsers display things (for example an h1) slightly differently but they have come to be more and more standardized due to recommendations from groups like W3C and WHATWG.

Now that we know the history of HTML, what is it now? How does it work?

How HTML Works

HTML documents are basically trees of elements and text. You have a start tag and end tag and in the middle there is text.

This is called an element.

 <p> content </p>

The HTML document is made up of many elements. You can open one element and have many others inside.

For example if you want to start the content for your page, you would include it in a body element. You would use a body start tag, put all the other elements you need inside, and then use a body close tag to say that you are finished.

You can also add “attributes” to these elements in order to make them do different things. An “a” element for example can have an href attribute that tells a browser to go to a different page when that element is clicked.

 <a href="https://url.com">
<p> content </p>
</a>

Once you are finished writing the HTML you can send it off to an HTML user agent. An HTML user agent is any software application that accesses, interprets, and renders HTML documents.

This is where some people get confused. They may ask something like “is HTML written in C”? But this is not the case. It is purely markup. Until a user agent parses it, it doesn’t actually DO anything.

In most cases this User Agent will be a web browser like Firefox or Google Chrome.

A web browser loads files from a server and displays them. Within the browser there is a browser engine. This engine figures out what to display based on the input.

The browser receives the HTML file in groups called packets in the form of bytes. Basically it receives packages of 1s and 0s that it can read.

It converts these into characters. For example a, b ,c or a greater than symbol. At this point the code is just a bunch of characters with no meaning.

Then these characters are converted into tokens. It recognizes patterns, for example, angle brackets enclosing the letter p. This is called the tokenization process.

These tokens are then converted into nodes. The nodes show everything about the content of the document. There are element nodes that tell everything about elements, Text nodes, and comment nodes.

You can think of them kind of like objects. They contain the properties of that object and everything it can do.

Once these nodes are created, the browser creates a tree structure called the Document Object Model Tree OR a DOM tree. It represents all the nodes and how they are connected to one another.

The browser also does this if there is a linked CSS file. It creates this same tree but it is called the CSSOM. Doesn’t quite flow off the tongue as well though.

These are combined to create the render tree.

After this, the mathematical formulae for where things will be displayed on the page is run. Basically they determine the location of items on the page. This is called reflow.

Next everything is “painted”. All the information is gather so now all the elements can be displayed on the page.

So basically, the render tree must be constructed first and then everything can be painted to the web page.

But what about JavaScript?

Well, when the HTML file is being parsed, if the browser sees a “script” tag it will actually stop all of the DOM tree from being constructed. It will pause everything and run the script.

So if you have ever placed your JS file at the top of an HTML document and you got a bunch of errors, now you know why. EXPLAIN WHY This is why we use a defer or async attribute or place the script tag below our HTML.

Another issue comes when the script is getting something from the internet. Let’s say you are in Toronto Canada and you want to fetch something in Tokyo. If you have this placed at the top of your document, you will have to wait for that file to be fetched completely before the DOM is even created.

Users could sit there looking at a blank page for a minute before anything would even be begin rendering.

That is a high level overview of HTML.

The Future of HTML

So what is the current state of HTML and what does the future hold?

At the moment there are some cool new features being implemented and others being worked on.

The dialog element, for example, is a newer feature that allows for an easier interface with modals directly in HTML and JavaScript and it already has widespread browser support.

Support for APIs like the geolocation API and Drag and Drop has really changed the face of web development as a whole. Allowing for some really interesting and seamless user experiences.

There looks to be a very strong push towards accessibility too.

However, the future of web development as a whole is clearly not just focused on HTML. It’s a combination of HTML, CSS and JavaScript that drive the web.

Historically, HTML has tried to separate itself from the other aspects of web development. While there are still many default stylings for different elements it has become more and more common to use ui libraries or CSS resets to completely do away with those default styles.

Even older html elements that concerned themselves with styling have been deprecated. And the elements that do technically still add styling (like strong and em for bolding and italics respectively) generally have a semantic use case or are useful for assistive technologies like Screen Readers.

Many developers hold this idea of the separation of concerns in HTML, CSS, and JavaScript as a guiding principle of web development. The golden rule.

HTML does the structure. CSS does the styling. Javascript does the logic.

But in recent years there has been considerable overlap.

Many applications are no longer developed using strictly HTML, CSS, and vanilla Javascript.

There are frameworks and libraries built on top of these technologies that really speed development time up.

React, for example, provides a great developer experience by seemingly placing the Javascript and HTML in the same file using something called JSX.

Frameworks like tailwind CSS allow users to write css as classes directly in the HTML file. It actually looks very similar to inlined CSS but it is fairly different.

Other technologies, like HTMX, seek to create a different developer experience still by adding much of the logic normally created in Javascript directly to HTML attributes themselves.

So where are the concerns separated?

Is it the frontend from the backend?

Or are things more modular? Should we keep all of the logic, styling, and semantics in a singular component, and then separate those components?

Now before I get a crowd of angry people yelling at me and telling me I’m incorrectly defining these technologies, I know I am. There is a lot more to all of these technologies.

But that’s why it is so tricky to figure out where HTML will go from here. Web development is no longer just placing HTML files on a server and hosting a static website. We've added CSS and JavaScript . We added jQuery to everything and then stopped using it. We have frameworks and libraries that change the development experience so much that new web developers are often starting with the frameworks and then working backwards to understand the technology underneath.

But at the end of the day, the browser is still reading that HTML. And that is really where it all started.