Web Technologies Hanging Out Together

Avatar of Chris Coyier
Chris Coyier on (Updated on )

As a beginner, understanding how the different languages you learn interact with each other can be confusing. I thought we could pair up a variety of languages to see where they intersect and communicate.


You need HTML to have CSS, because HTML calls the CSS. In an HTML document, you’ll likely see some HTML like this:

<link rel="stylesheet" href="style.css">

That is an HTML element (<link>) calling some CSS that will then be applied to the HTML. Or you might see a “style block” like this:

<!-- this <style> tag is HTML -->
  /* The stuff in here is CSS */
  .message {
     padding: 20px;
     background: lightyellow;
     border: 1px solid yellow;

The typical connection between HTML and CSS is with selectors. An HTML element might have an ID or class, which doesn’t do much by itself, but is there for CSS to find it and style it. Like:

<div class="module message">
  <h2 class="positive">
    Good afternoon!
    You look nice today.
.module { /* will apply to <div class="module message"> */
  padding: 20px;
  background: rgba(0, 0, 0, 0.2);
.message { /* will apply to <div class="module message"> */
  border: 1px solid yellow;
.positive { /* will apply to <h2 class="positive"> */
  color: lightblue;
  font-weight: bold;

CSS can even be applied directly to elements in HTML. In that case there is no selector, just properties and values:

<div style="padding: 10px; background: red; color: white;">

Using CSS this way is generally frowned upon because it doesn’t take advantage of what HTML and CSS do so wonderfully together: separate content and style.

HTML and JavaScript

You need HTML to call JavaScript. In an HTML document, you might see:

<script src="script.js"></script>

That is an HTML element (<script>) that calls a JavaScript file that will then run in that document. Or you might see a script tag with no source, an inline script block:

<!-- the <script> tag is HTML -->
  // The stuff in here is JavaScript
  var header = document.getElementById("main-header");

You might also see JavaScript directly on HTML elements, like this:

<button onclick="doSomething();"></button>

Using JavaScript “inline” like that is generally frowned upon, because it isn’t very efficient and doesn’t separate the concerns of content and interaction.

Another relationship between HTML and JavaScript is that JavaScript can control the DOM. The DOM is essentially what HTML turns into when a browser reads it. You can read more about that here.

JavaScript can create new HTML and insert it onto the page:

// Create new element
var modal = document.createElement('div');

// Set attributes and content
modal.id = "modal";
modal.innerHTML = "\
  <h1>Important Message</h1>\
  <p>You're cool.</p>";

// Put in the <body>

JavaScript can remove elements from the page as well:

var reference = document.getElementById("goner");

JavaScript can alter the content of existing elements as well:

var reference = document.querySelectorAll("#modal > h1");
reference[0].innerHTML = "This title has been changed by JS!";

JavaScript and CSS

JavaScript can find out about an element’s style:

<div style="color: red;" id="test">test</div>
  var div = document.getElementById("test");
  // red

  // and/or *set* it like:
  div.style.padding = "10px";

But that only works for an elements inline style attribute (or styles set in that way). JavaScript can also get all the styles on an element, even those that came from CSS elsewhere:

  .test {
     margin: 30px;

<div class="test"></div>

  var div = document.querySelectorAll(".test")[0];

  var styles = getComputedStyle(div);

  // 30px

More commonly, because JavaScript is our primary means of handling interactivity on websites, we use it to control other elements. Here’s a simple example of a button that, when clicked, toggles the whether you can see another element or not:

<button class="button">Toggle Another Element</button>

<div id="message">Message</div>
var button = document.querySelectorAll(".button")[0];
var message = document.querySelectorAll("#message")[0];

button.addEventListener("click", function() {
  if (message.style.display == "block") {
    message.style.display = "none";
  } else {
    message.style.display = "block";

Perhaps even more common (and generally considered to be responsible) is to only manipulate class names on elements, rather than styles directly. Then let CSS handle the styles (which includes whether it is visible or not). It ends up being easier anyway:

#message {
  display: none;
#message.show {
  display: block;
var button = document.querySelectorAll(".button")[0];
var message = document.querySelectorAll("#message")[0];

button.addEventListener("click", function() {
}, false);

See the Pen qidGm by Chris Coyier (@chriscoyier) on CodePen.


The HTML you work with might actually be in a back end language like PHP and is processed and delivered as HTML. Imagine a template for a blog:

  <?php echo $postTitle; ?>
<div class="post-content">
  <?php echo $postContent; ?>

In this article we’re just using PHP as an example of a backend language. But it could just as easily be Ruby or Python or the like.

You’ll recognize HTML there, but PHP mingled in. That is just a generic example of outputting values that a backend language might be in charge of. The web browser never sees the code like that. By the time it makes it to the browser, it will look like regular HTML:

  How To Survive A Flight Delay Without Tweeting About It
<div class="post-content">
  Step one, grow up.

As a front end person, you might think of PHP as the link between information in a database and HTML.

Another possibility would be outputting different HTML based on information you know on the server.

<?php $userLikesCheese = doesUserLikeCheese($user); ?>

<?php if ($userLikesCheese) { ?>
  <div class="modal">
    Congrats on loving cheese, cheese lover!
<?php } else { ?>
  <div class="modal">
    Some other way more boring widget.
<?php } ?>

PHP and JavaScript

Speaking of a database, you might need information that comes from the server in JavaScript.

JavaScript also has the ability to make a request to a URL all on its own. Imagine clicking a “like” button on a page. You wouldn’t expect that to refresh the entire page. Instead, that action might make a request to a PHP file on your server that’s job it is to save that information.

var button = document.querySelectorAll(".button")[0];

button.addEventListener("click", function() {
  var xhr = new XMLHttpRequest();
  xhr.onload = likeSuccess;
  xhr.open("get", "/save_like.php", true);

function likeSuccess() {
  button.innerHTML = "You Like Stuff!";

See the Pen gomvI by Chris Coyier (@chriscoyier) on CodePen.


Just like PHP documents can be processed and served as HTML, the same can happen with CSS. This means you could do things like utilize the power of PHP variables in CSS. I’ve written about this before, but I’d argue today this isn’t a particularly good idea. I’d recommend instead taking a look at CSS preprocessing.

Another connection is using PHP to alter class names or attributes, and then CSS acts accordingly.

<body class="<?php echo $bodyClass; ?>">

     Probably a logo and stuff.

header {
  height: 100px;

/* header is bigger on homepage */
body.home header {
  height: 200px;

Of course it gets way more complicated.

It should go without saying, right? Sometimes it just is. But these aren’t just “the basics” – they are foundational concepts that more complicated things are built from.

Perhaps you learned how to make an Ajax request with jQuery and it doesn’t look like the one I did above. Well, somewhere in that jQuery library, which is written in JavaScript, it’s doing that same thing. It’s just got some extra stuff in there to make sure it works in older browsers and adds convenience for you.

Perhaps you’re using Angular and the way you change stuff on the page is with weird {{angle brackets}} in your HTML. That’s nifty, but somewhere Angular is doing something with “raw” JavaScript. An .innerHTML is being used or a node is being replaced, who knows. The people who work on Angular figured out the best way to do it and that’s what it does.

Maybe the CMS you use at work has some different looking templating system. That’s cool. I’ll bet you a billion bucks it gets turned into HTML before it hits the browser, because that’s how this all goes down.

The point: it’s all related.

You can be better at some of these languages than others. All of us are. Totally fine. But it is important to understand how they fit together. That’s all of our jobs.

My inspiration for this came from my own utter confusion when I’d hear someone from some startup rattle off their “tech stack” and I just didn’t comprehend how all those things could possibly fit together to build one thing. I’m still confused, but it doesn’t matter. I understand how the parts fit together well enough that any part I’ve never heard of is surely just some newfangled way to handle the same pieces of the web tech pie that we all deal with.