HTML, a Freak in the Stylesheets — What on Earth is HTML pt III
HTML is not a programming language, writes Ben Romy in this explanation. As its name suggests, HTML is a markup language. It doesn’t contain programming logic like JavaScript does. It simply structures content like text, images, and hyperlinks.
This article on browser rendering by Ohans Emmanuel does a great job of helping me to understand Ben Romy’s point. In talking about how the browser engine itself is in charge of deciding how to interpret and display HTML, I infer that this means that HTML code itself is relatively unopinionated about how it should be displayed to the page.
This makes sense: HTML and CSS are governed by W3C standards. In my mind, I just imagine the Star Wars senate: a faraway, bureaucratic body of aliens, who hover in some auditorium that looks like it was designed by James Turell. There, they discuss the rules of computer languages that run our galaxy, languages that convey information across vast distances, near the speed of light.
However, the governed here are not nation-states in Star Wars, though that’s close. Instead, we are talking about companies like Google, Apple, Microsoft, and Opera, which maintain the browsers that display webpages. Their implementations of these standards will tend to differ, although that may change as Google’s browser engine Blink captures more of the browser market.
Given that HTML is governed by not-entirely-adhered-to standards, rather than being maintained by a team of developers, the point that HTML isn’t a programming language makes some sense. You wouldn’t expect to hear someone say “JavaScript will do X if it’s running in Chrome, but Y if it’s running in Firefox.” However, this is exactly what you see with HTML across different browsers. Exhibit A, the <a> tag:
This all supports my understanding that HTML really is just a tagging system for wrapping elements and not giving so much as describing a web page’s structure. HTML itself doesn’t actually do much. It gets read. Whoever reads it is what matters.
I wonder if some people feel this at first to be a relatively unimportant detail, trivia. It definitely doesn’t feel that way to me. For one thing, it answers a big question I had: how does HTML create elements on the page? How does HTML handle logic?
The question is a red herring: HTML doesn’t do any of these things. HTML passes the buck to the browser, or more specifically, the browser engine. So in my understanding, there isn’t something more to look for in HTML, there is nothing hiding behind the text when I write this line of code: <a href=“#”> Generic Hyperlink </a>. HTML is basically explicable by just two ideas:
- tag + text = element
- (element + element) * properNesting = HTML document
Going over what I’ve written so far — now that I understand this stuff — some of these parts seem a bit redundant. So if you’re already on board with all this, you might find the rest of this post repetitive. However, this took a while to click for me, so I want to share some of the formulations that helped me make sense of what HTML is, what a web page is, and the difference.
HTML doesn’t do anything dynamic. HTML is a blueprint describing a house. The browser engine is the architect, interior designer, and electrician who actually reads the plans–HTML, CSS, and JS, respectively–and then constructs the house.
In reality, that’s still an oversimplification. Browsers have a separate JavaScript engine, which is separate, but obviously deeply connected to the workings of the browser engine. However, for me trying to understand what on earth HTML is/does, the point remains that HTML just “is”, it doesn’t “does” anything. I’m using bad grammar to emphasize here. Which part of the browser is transforming HTML into a web page that I as a user can manipulate is less important to me at this moment than understanding that even with an HTML document, without the browser engine, there’s no web page.
For the sake of efficiency, this makes sense: if HTML contained all the information needed to display a website, the size of every website would be much larger, and the internet would be a lot slower. You wouldn’t want to have to download an entire web browser’s worth of data every time you visit any website. That’d be a lot more packets getting sent across the web.
Another oversimplification I need to point out relates to how HTML/CSS/JS are compiled. From HTML, the browser creates the DOM. From CSS, the browser creates the CSSOM. CSS is actually called Cascading Stylesheets because of the relationship between the DOM and how CSS has to be applied to integrate the two: the DOM is a tree of nodes/HTML elements, and since child elements can inherit styles from their parents, but also have those styles overwritten, CSS needs to recursively “cascade” over and down the DOM tree in order to style it. The combination of the DOM and CSSOM is the render tree, which contains all the information about how the web page should look. However, different devices exist, different viewports exist, so the render tree still has to be painted onto the screen in the layout or “reflow” step.
Like so many things, with this level of remove, my initial qualm now seems meaningless. You never touch the HTML. You never really get close. After all, we’re behind a wall of glass. So what is HTML? I guess it’s a set of markup instructions to the browser engine. Our HTML, CSS, and JS, has all been compiled into a unitary render tree that has been painted onto the page.
That render tree then communicates new inputs and interactions with the elements/objects underlying its construction by tracking the location of elements on the screen, so it knows when a particular element should fire off an event, in reaction to a keystroke, mouseover, click, etc.
I feel like I got to the end of an episode of Dragon Ball Z; Goku is still hollering while he powers up, and absolutely nothing has happened. Likewise, HTML is an unsatisfying dead end for trying to understand the mechanics of how HTML actually shows up on the page. It’s just another cliffhanger. Looks like I need to write a post about browser engines now!
Main Sources
- How browser rendering works — behind the scenes
- Why HTML is Not a Programming Language by Ben Romy
- Part 3 and Part 4 of Mariko Kosaka’s Inside look at modern web browser series
- Why some websites don’t work properly in your favorite browser — MacWorld
References
Further HTML Questions I’d like to explore:
- How do browser engines work
- HTML attributes
- Non-arbitrary explanations for why some HTML features are tags and others attributes. Is it only arbitrary? Like how JS is arbitrary with prepended functions vs. appended methods, e.g.:
let string = “5”; parseInt(string); // => 5
let number = 6; number.toString(); // => “6”