syntax – CSS-Tricks

Why (and How) I Write Code With Pencil and Paper

Preethi — Wed, 17 Aug 2022 13:21:17 +0000

If the thought of handwriting code seems silly, it might surprise you to know that it’s inevitable. If you’re unsure, think about the last job interview you did, and remember how there was no computer around in the interview room — just your interviewers, a blank sheet of paper, and a blue ball-point pen.

For the students among you, it’s even a bigger deal as your grades hang in by the lines of code you had strategically squeezed into the available space in your answer sheet.

And not just that, experienced programmers can point you to the bundle of A4 sheets they had removed from the office copy machine to scribble down a particularly complex algorithm they had been working on.

So whether you’re an exam student, potential job interviewee, or someone wanting to resolve their programming dead ends, I hope this article helps you out when you put your pen to the paper to code.

Although I will focus on the analog aspect of writing code, you can apply these steps to coding in any form or language. So consider this to be also like a generic coding guideline that works specifically for me but can also be very useful to you in your work.

Why write it down?

Before we start, it’s essential to understand that no one expects you to jot down production-ready code in a notebook. It’s not like you can drop that into a code editor and compile it without an error. If producing perfect code was the goal, you would be seated in front of a computer in the interview rooms and exam halls.

The purpose of handwriting code is to work through logic in advance. There’s s desire to “get in the browser” as soon as possible in design, but there is conventional wisdom in sketching designs by hand. A low-fidelity medium encourages quick experimentation and inexpensive mistakes.

The toil of trying to figure out how to affect surrounding items with one click (from my last article)

The same can be true of code, mainly when working out syntax and semantics. That said, getting the correct syntax and semantics is always a plus point, though not the sole focus of the whole handwriting exercise.

Let’s see where we can start when it comes to handwriting code.

Know your question

During my final year in college, I couldn’t do an internship or even attend campus interviews because of health reasons. As a result, my very first job interview was quite literal with high stakes.

When I look back now, the interview was pretty easy. But having never attended one before, I was anxious beyond reason. The first thing the interviewers asked about programming was if I could output an inverted triangle made of asterisks. As I said, it was easy — nothing a for loop can’t handle, right? But like I said, my anxiety was through the roof as well.

I took a deep breath, pressed my palm against the blank sheet of paper they had laid out for me, slid it as slow as possible towards me on the table (buying time, of course), clicked the pen, and then I did something right.

I first drew an inverted triangle made of asterisks. That’s how I found my feet on the ground to start answering their question.

I’ve seen otherwise brilliant developers get something wrong simply because they never fully grasp what it is they are solving.

The questions we work with are not like the questions physicists or mathematicians solve. They get a set of parameters and find the missing ones; our questions are also our results. We are already told what our results are — we have to figure out how to reach them. That’s why it’s imperative to know the question well because you’ll see the result.

Writing down or drawing out what you want to output is one of the best ways to start your coding. I understand that in our fast-paced industry, the expectation is that we have to jump right into the programming by running a “hello world” demo. And that’s great to familiarize yourself with an unfamiliar syntax and shake off your anxiousness about trying something new.

But when someone asks you a question and gives you a result to work up to, wouldn’t it just be better to put that down first? That question/result is not only your starting point but also your point of reference. At any step in your coding, you can look at it to ensure you’re working towards it and that you’re on the right track.

So whether in your answer sheets or in that blank A4 paper you’re about to write in, start by taking a second and writing down what it is you’re trying to output. You can put it in the margins or a corner if you don’t want it to be a part of your answer. Just make sure it’s somewhere where you can keep referencing it.

Outline your code

This step is like a double-edged sword. It can get you a roadmap to your program or waste your time. My job is to make sure it’s the former.

So, first and foremost, I like to say: outlining code is unnecessary if the scope of your problem or question is small. Again, this practice is neither prescriptive nor universal to all projects or situations. Imagine I’m your interviewer, and I ask you to write how to center an element in a web page using CSS in as many ways as possible. You won’t exactly be needing an outline for this. The code snippets are relatively small for each method.

But now, let’s say I assign you to write a web application that captures user signatures via a touchscreen interface and then saves the signature on the server. Not so straightforward, right? You’ve more than one thing to figure out. Perhaps, a little outline can help.

UI for capturing signature — HTML Canvas? WebGL?
Disable pointer events on the rest of the web page when the user is signing
Convert and save the captured image to a PNG file — JS
Then convert it to blob (maybe) and save it to the visitor’s log data table.

I’ve written a rough sequence of actions I think I might have to code. It could’ve been shorter or longer, depending on what I wanted from it.

I highly recommend outlining code for client projects. Write the outline along with your user requirements or on the back of wireframes you’ve printed out.

Your quick snapshot of bullet points gives you a map, a to-do list, and a checklist to verify against when you reach the end of the project — pretty much your whole project’s summary in a low-fidelity list. It can also become a template to start your next similar project.

But like I said before, this step is like a double-edged sword. You’ll have to keep this short for examinees and interviewees when there are time constraints.

If you don’t know where to start, write down just three essential functions you’ll have to code in your application, and if you have got the time, make it five.

But that’s about it. Spend as little time as possible on this, and don’t sweat over the details. The outline is not going to score you extra points. It’s there only to help you make sure you have everything covered. It captures your initial gut reaction and keeps you honest throughout the project’s life.

Longhand vs. shorthand

A quick reference to disable text selection

Time to start coding. So, what do you write? “Bdrs” or “border-radius“; “div -> p” or “

“; “pl()” or “println()“; “q()” or “querySelector()“?

If someone else is grading your code, then there’s no choice. Leave out abbreviations, pseudo-codes, Emmet shortcuts, and any other form of shorthand writing. Otherwise, there’s no reason to assume that anyone reading this knows what your abbreviations mean.

It’s really up to you.

If you’ve gotten out of touch with writing by hand — and many of us have — it’s better not to go overboard with the longhand notations, as they get tedious. At the same time, there’s no such thing as being too frugal with your writing. Not if you want to be able to look back on it one day and understand what you’d written down.

I have an open file in my note-taking app and a lined notepad on my desk where I write down code snippets I want to save for later reference. They are unorganized, just a long stream of snippets. That’s why when I browse through older notes, I wouldn’t know what I meant to write if I had not written them down clearly.

I forget syntaxes all the time. For instance, I’ve been using the arrow notation for JavaScript functions since it was introduced (because it’s shorter), and I’m pretty sure if someone suddenly asks me to define a function using the function keyword, I might even misplace the parentheses or the function name, inciting a syntax error.

It’s not unusual for us to forget syntaxes we haven’t used in a while. That’s why it’s better to write your notes clearly when you know you need them for future reference.

The non-sequential flow of code

Unlike the last step, which doesn’t apply to those of you interviewees and test-takers, this one is catered especially to you.

Most programming languages are interpreted, compiled, and executed so that sometimes pre-written code in the source is executed later when called. We do it in JavaScript, for example, with function calling — functions can be defined initially, then executed later. Examinees and interviewees can use this to start working on the critical point of your answer first.

As I’ve said from the very beginning, the purpose of handwriting code is to work through or test the logic of whatever it is you program. It’s best when you focus on resolving that first.

Let’s take a classic textbook example — a program to find the nth Fibonacci number. If I were to write a simple outline for it, it would be something like this:

Get the input.
Calculate the Fibonacci number.
Summarise the output.
Print the output.

All the steps in that outline are essential; however, 1, 3, and 4 are more obligatory. They are necessary but not important enough to focus on right away.

It’s better to start writing down the code to calculate the Fibonacci number rather than to fetch the input. Wrap it in a function, then go ahead and write the code sequentially and write down a line to call that function where appropriate.

Spend your time writing code that focuses on the heart of the problem.

Real professionals can skip ahead. Let’s say I have a client project, and I have to work with some triangle geometry — got two sides, opposite angle, and gotta find the third side’s length. And I’ve decided to scribble on paper to get started rather than opening my IDE.

First, I would draw the triangle, of course (that’s something I’m very experienced with, as you can tell). I would write down some sample lengths and angles. Then I’d write the formula (compliments of online searching, for sure), and then I’d jump right to the code for the function.

There’s no point in me writing down the obligatory steps even though I’ll need them in production-ready code. But it would be different if I had to write that on an answer sheet in an exam. I can’t skip the other steps; however, I can still start with the code for the formula.

Pseudo-code

Chris has already written a handy article on pseudo-code that I highly recommend you give a solid read.

For all those professionals who feel like the whole handwriting code thing doesn’t seem like your cup of tea but still might be curious if it can help you, then pseudo-code might be the balance you’re looking for.

It’s similar to outlining the code, as I mentioned in one of the previous steps. However, it’s briefer and feels more like shorthand coding. It’s sometimes also referred to as “skeleton code.”

Here’s some quick pseudo-code for a CSS grid layout:

Grid
5 60px rows
6 100px columns

There isn’t much to write! So, even though putting a pencil to paper is excellent for this sort of thing, it’s just as effective, fast, and inexpensive to jot some pseudo code into whatever program you’re using.

Space and comments

I believe code is 90% keywords and 10% tabs. Withoutspacesthereadabilityofwordsdecreases. Indentations are necessary for handwritten code as well. However, please don’t use it for every level because the width of the paper will limit you. Use spaces judiciously, but use them.

Prized OG snippet, written with extra TLC

If you’re writing code for your use, I also believe that if you’ve followed everything I’ve mentioned so far and have already written down your output and an outline on the page, you may not even need to include comments. Comments tell you quickly what its following set of code does. If you have already written and read an outline for the code, then comments are redundant notes.

However, if your judgment says to put down one, then do it. Add it to the right side of the code (since you won’t be able to insert it between already written lines the way you could in, say, VS Code). Use forward slashes, brackets, or arrows to denote that they are comments.

For examinees who are unconfident with a certain syntax, write down comments. This way, at least, you’re letting the person grading your paper know your intention with that incorrectly formatted code. And use only the correct delimiters to denote comments — for example, that would be the forward slashes for JavaScript.

Analog vs. digital

As I mentioned earlier, everything I’m providing here can is generic coding advice. If you don’t want to try this with physical paper, any note-taking application also works.

But if you’re going to try the digital route, my recommendation is to try using something other than a straight note-taking app. Work with more visual digital tools — flow diagrams, mind maps, wireframes, etc. They can help you visualize your result, the outlines, and the code itself.

I am not much of a digital citizen (except for working on the web and recently converting to reading e-books), so I stick to physical notebooks.

My favorite tools for handwriting code

Any pencil and paper will do! But there are lots of options out there, and these are a few choice tools I use:

Staedtler Pigment Liner 0.3mm (Black)
Mitsubishi JETSTREAM 101 0.7mm (Black)
MUJI Notebook A5 6mm Rule 30 sheets (Lightweight and easy to carry)
MUJI Twin-Tip Highlighter Pen (Yellow)

There is no “write” way to code

I hope, if nothing else, my little way of handwriting code with pencil and paper makes you evaluate the way you already plan and write code. I like knowing how other developers approach their work, and this is my way of giving you a peek into the way I do things.

Again, nothing here is scientific or an exact art. But if you want to give handwritten code planning a try, here’s everything we’ve covered in a nice ordered list:

Start by writing down (with sample data, if needed) the output of your code.
Write an outline for the code. Please keep it to three steps for small projects or ones that are less complex.
Use longhand notations. Developers writing for themselves can use shorthand notations as long as the writing is legible and makes sense to you when you refer to it later.
When under a time constraint, consider writing the code that tackles the heart of the problem first. Later, write down a call to that code at the right place in your sequential code.
If you feel confident, try writing pseudo code addressing the main idea.
Use proper indentations and spaces — and be mindful of the paper’s width.

That’s it! When you’re ready to try writing code by hand, I hope this article makes it easy for you to start. And if you’re sitting down for an exam or an interview, I hope this helps you focus on getting the questions right.

Why (and How) I Write Code With Pencil and Paper originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Syntax Highlighting (and More!) With Prism on a Static Site

Adam Rackis — Wed, 04 May 2022 14:16:43 +0000

So, you’ve decided to build a blog with Next.js. Like any dev blogger, you’d like to have code snippets in your posts that are formatted nicely with syntax highlighting. Perhaps you also want to display line numbers in the snippets, and maybe even have the ability to call out certain lines of code.

This post will show you how to get that set up, as well as some tips and tricks for getting these other features working. Some of it is tricker than you might expect.

Prerequisites

We’re using the Next.js blog starter as the base for our project, but the same principles should apply to other frameworks. That repo has clear (and simple) getting started instructions. Scaffold the blog, and let’s go!

Another thing we’re using here is Prism.js, a popular syntax highlighting library that’s even used right here on CSS-Tricks. The Next.js blog starter uses Remark to convert Markdown into markup, so we’ll use the remark-Prism.js plugin for formatting our code snippets.

Basic Prism.js integration

Let’s start by integrating Prism.js into our Next.js starter. Since we already know we’re using the remark-prism plugin, the first thing to do is install it with your favorite package manager:

npm i remark-prism

Now go into the markdownToHtml file, in the /lib folder, and switch on remark-prism:

import remarkPrism from "remark-prism";

// later ...

.use(remarkPrism, { plugins: ["line-numbers"] })

Depending on which version of the remark-html you’re using, you might also need to change its usage to .use(html, { sanitize: false }).

The whole module should now look like this:

import { remark } from "remark";
import html from "remark-html";
import remarkPrism from "remark-prism";

export default async function markdownToHtml(markdown) {
  const result = await remark()
    .use(html, { sanitize: false })
    .use(remarkPrism, { plugins: ["line-numbers"] })
    .process(markdown);

  return result.toString();
}

Adding Prism.js styles and theme

Now let’s import the CSS that Prism.js needs to style the code snippets. In the pages/_app.js file, import the main Prism.js stylesheet, and the stylesheet for whichever theme you’d like to use. I’m using Prism.js’s “Tomorrow Night” theme, so my imports look like this:

import "prismjs/themes/prism-tomorrow.css";
import "prismjs/plugins/line-numbers/prism-line-numbers.css";
import "../styles/prism-overrides.css";

Notice I’ve also started a prism-overrides.css stylesheet where we can tweak some defaults. This will become useful later. For now, it can remain empty.

And with that, we now have some basic styles. The following code in Markdown:

```js
class Shape {
  draw() {
    console.log("Uhhh maybe override me");
  }
}

class Circle {
  draw() {
    console.log("I'm a circle! :D");
  }
}
```

…should format nicely:

Adding line numbers

You might have noticed that the code snippet we generated does not display line numbers even though we imported the plugin that supports it when we imported remark-prism. The solution is hidden in plain sight in the remark-prism README:

Don’t forget to include the appropriate css in your stylesheets.

In other words, we need to force a .line-numbers CSS class onto the generated

 tag, which we can do like this:







And with that, we now have line numbers!







Note that, based on the version of Prism.js I have and the “Tomorrow Night” theme I chose, I needed to add this to the prism-overrides.css file we started above:



.line-numbers span.line-numbers-rows {
  margin-top: -1px;
}



You may not need that, but there you have it. We have line numbers!


Highlighting lines


Our next feature will be a bit more work. This is where we want the ability to highlight, or call out certain lines of code in the snippet.



There’s a Prism.js line-highlight plugin; unfortunately, it is not integrated with remark-prism. The plugin works by analyzing the formatted code’s position in the DOM, and manually highlights lines based on that information. That’s impossible with the remark-prism plugin since there is no DOM at the time the plugin runs. This is, after all, static site generation. Next.js is running our Markdown through a build step and generating HTML to render the blog. All of this Prism.js code runs during this static site generation, when there is no DOM.



But fear not! There’s a fun workaround that fits right in with CSS-Tricks: we can use plain CSS (and a dash of JavaScript) to highlight lines of code.



Let me be clear that this is a non-trivial amount of work. If you don’t need line highlighting, then feel free to skip to the next section. But if nothing else, it can be a fun demonstration of what’s possible.


Our base CSS


Let’s start by adding the following CSS to our prism-overrides.css stylesheet:



:root {
  --highlight-background: rgb(0 0 0 / 0);
  --highlight-width: 0;
}

.line-numbers span.line-numbers-rows > span {
  position: relative;
}

.line-numbers span.line-numbers-rows > span::after {
  content: " ";
  background: var(--highlight-background);
  width: var(--highlight-width);
  position: absolute;
  top: 0;
}



We’re defining some CSS custom properties up front: a background color and a highlight width. We’re setting them to empty values for now. Later, though, we’ll set meaningful values in JavaScript for the lines we want highlighted.



We’re then setting the line number  to position: relative, so that we can add a ::after pseudo element with absolute positioning. It’s this pseudo element that we’ll use to highlight our lines.


Declaring the highlighted lines


Now, let’s manually add a data attribute to the 
 tag that’s generated, then read that in code, and use JavaScript to tweak the styles above to highlight specific lines of code. We can do this the same way that we added line numbers before:







This will cause our 
 element to be rendered with a data-line="3,8-10" attribute, where line 3 and lines 8-10 are highlighted in the code snippet. We can comma-separate line numbers, or provide ranges.



Let’s look at how we can parse that in JavaScript, and get highlighting working.


Reading the highlighted lines


Head over to components/post-body.tsx. If this file is JavaScript for you, feel free to either convert it to TypeScript (.tsx), or just ignore all my typings.



First, we’ll need some imports:



import { useEffect, useRef } from "react";



And we need to add a ref to this component:



const rootRef = useRef(null);



Then, we apply it to the root element:







The next piece of code is a little long, but it’s not doing anything crazy. I’ll show it, then walk through it.



useEffect(() => {
  const allPres = rootRef.current.querySelectorAll("pre");
  const cleanup: (() => void)[] = [];

  for (const pre of allPres) {
    const code = pre.firstElementChild;
    if (!code || !/code/i.test(code.tagName)) {
      continue;
    }

    const highlightRanges = pre.dataset.line;
    const lineNumbersContainer = pre.querySelector(".line-numbers-rows");

    if (!highlightRanges || !lineNumbersContainer) {
      continue;
    }

    const runHighlight = () =>
      highlightCode(pre, highlightRanges, lineNumbersContainer);
    runHighlight();

    const ro = new ResizeObserver(runHighlight);
    ro.observe(pre);

    cleanup.push(() => ro.disconnect());
  }

  return () => cleanup.forEach(f => f());
}, []);



We’re running an effect once, when the content has all been rendered to the screen. We’re using querySelectorAll to grab all the 
 elements under this root element; in other words, whatever blog post the user is viewing.



For each one, we make sure there’s a  element under it, and we check for both the line numbers container and the data-line attribute. That’s what dataset.line checks. See the docs for more info.




If we make it past the second continue, then highlightRanges is the set of highlights we declared earlier which, in our case, is "3,8-10", where lineNumbersContainer is the container with the .line-numbers-rows CSS class.



Lastly, we declare a runHighlight function that calls a highlightCode function that I’m about to show you. Then, we set up a ResizeObserver to run that same function anytime our blog post changes size, i.e., if the user resizes the browser window.


The highlightCode function


Finally, let’s see our highlightCode function:



function highlightCode(pre, highlightRanges, lineNumberRowsContainer) {
  const ranges = highlightRanges.split(",").filter(val => val);
  const preWidth = pre.scrollWidth;

  for (const range of ranges) {
    let [start, end] = range.split("-");
    if (!start || !end) {
      start = range;
      end = range;
    }

    for (let i = +start; i <= +end; i++) {
      const lineNumberSpan: HTMLSpanElement = lineNumberRowsContainer.querySelector(
        `span:nth-child(${i})`
      );
      lineNumberSpan.style.setProperty(
        "--highlight-background",
        "rgb(100 100 100 / 0.5)"
      );
      lineNumberSpan.style.setProperty("--highlight-width", `${preWidth}px`);
    }
  }
}



We get each range and read the width of the 
 element. Then we loop through each range, find the relevant line number , and set the CSS custom property values for them. We set whatever highlight color we want, and we set the width to the total scrollWidth value of the  element. I kept it simple and used "rgb(100 100 100 / 0.5)" but feel free to use whatever color you think looks best for your blog.



Here’s what it looks like:






Line highlighting without line numbers


You may have noticed that all of this so far depends on line numbers being present. But what if we want to highlight lines, but without line numbers?



One way to implement this would be to keep everything the same and add a new option to simply hide those line numbers with CSS. First, we’ll add a new CSS class, .hide-numbers:



```js[class="line-numbers"][class="hide-numbers"][data-line="3,8-10"]
class Shape {
  draw() {
    console.log("Uhhh maybe override me");
  }
}

class Circle {
  draw() {
    console.log("I'm a circle! :D");
  }
}
```



Now let’s add CSS rules to hide the line numbers when the .hide-numbers class is applied:



.line-numbers.hide-numbers {
  padding: 1em !important;
}
.hide-numbers .line-numbers-rows {
  width: 0;
}
.hide-numbers .line-numbers-rows > span::before {
  content: " ";
}
.hide-numbers .line-numbers-rows > span {
  padding-left: 2.8em;
}



The first rule undoes the shift to the right from our base code in order to make room for the line numbers. By default, the padding of the Prism.js theme I chose is 1em. The line-numbers plugin increases it to 3.8em, then inserts the line numbers with absolute positioning. What we did reverts the padding back to the 1em default.



The second rule takes the container of line numbers, and squishes it to have no width. The third rule erases all of the line numbers themselves (they’re generated with ::before pseudo elements).



The last rule simply shifts the now-empty line number  elements back to where they would have been so that the highlighting can be positioned how we want it. Again, for my theme, the line numbers normally adds 3.8em worth of left padding, which we reverted back to the default 1em. These new styles add the other 2.8em so things are back to where they should be, but with the line numbers hidden. If you’re using different plugins, you might need slightly different values.



Here’s what the result looks like:






Copy-to-Clipboard feature


Before we wrap up, let’s add one finishing touch: a button allowing our dear reader to copy the code from our snippet. It’s a nice little enhancement that spares people from having to manually select and copy the code snippets.



It’s actually somewhat straightforward. There’s a navigator.clipboard.writeText API for this. We pass that method the text we’d like to copy, and that’s that. We can inject a button next to every one of our  elements to send the code’s text to that API call to copy it. We’re already messing with those  elements in order to highlight lines, so let’s integrate our copy-to-clipboard button in the same place.




First, from the useEffect code above, let’s add one line:



useEffect(() => {
  const allPres = rootRef.current.querySelectorAll("pre");
  const cleanup: (() => void)[] = [];

  for (const pre of allPres) {
    const code = pre.firstElementChild;
    if (!code || !/code/i.test(code.tagName)) {
      continue;
    }

    pre.appendChild(createCopyButton(code));



Note the last line. We’re going to append our button right into the DOM underneath our 
 element, which is already position: relative, allowing us to position the button more easily.



Let’s see what the createCopyButton function looks like:



function createCopyButton(codeEl) {
  const button = document.createElement("button");
  button.classList.add("prism-copy-button");
  button.textContent = "Copy";

  button.addEventListener("click", () => {
    if (button.textContent === "Copied") {
      return;
    }
    navigator.clipboard.writeText(codeEl.textContent || "");
    button.textContent = "Copied";
    button.disabled = true;
    setTimeout(() => {
      button.textContent = "Copy";
      button.disabled = false;
    }, 3000);
  });

  return button;
}



Lots of code, but it’s mostly boilerplate. We create our button then give it a CSS class and some text. And then, of course, we create a click handler to do the copying. After the copy is done, we change the button’s text and disable it for a few seconds to help give the user feedback that it worked.



The real work is on this line:



navigator.clipboard.writeText(codeEl.textContent || "");



We’re passing codeEl.textContent rather than innerHTML since we want only the actual text that’s rendered, rather than all the markup Prism.js adds in order to format our code nicely.



Now let’s see how we might style this button. I’m no designer, but this is what I came up with:



.prism-copy-button {
  position: absolute;
  top: 5px;
  right: 5px;
  width: 10ch;
  background-color: rgb(100 100 100 / 0.5);
  border-width: 0;
  color: rgb(0, 0, 0);
  cursor: pointer;
}

.prism-copy-button[disabled] {
  cursor: default;
}



Which looks like this:







And it works! It copies our code, and even preserves the formatting (i.e. new lines and indentation)!


Wrapping up


I hope this has been useful to you. Prism.js is a wonderful library, but it wasn’t originally written for static sites. This post walked you through some tips and tricks for bridging that gap, and getting it to work well with a Next.js site.

Syntax Highlighting (and More!) With Prism on a Static Site originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.



Creating an Editable Textarea That Supports Syntax-Highlighted Code
Oliver Geer — Fri, 16 Apr 2021 18:58:59 +0000

When I was working on a project that needed an editor component for source code, I really wanted a way to have that editor highlight the syntax that is typed. There are projects like this, like CodeMirror, Ace, and Monaco, but they are all heavy-weight, full-featured editors, not just editable textareas with syntax highlighting like I wanted.



It took a little finagling, but I wound up making something that does the job and wanted to share how I did it, because it involves integrating a popular syntax highlighting library with HTML’s editing capabilities, as well as a few interesting edge cases to take into consideration.







Live syntax highlighting while you type



Go ahead and give it a spin as we dig in!



After a suggestion, I have also released this as a custom element on GitHub, so you can quickly use the component in a webpage as a single  element.



CodePen Embed Fallback


The problem


First, I tried using the contenteditable attribute on a div. I typed some source code into the div and ran it through Prism.js, a popular syntax highlighter, on oninput via JavaScript. Seems like a decent idea, right? We have an element that can be edited on the front end, and Prism.js applies its syntax styling to what’s typed in the element.



Chris covers how to use Prism.js in this video.



But that was a no-go. Each time the content in the element changes, the DOM is manipulated and the user’s cursor is pushed back to the start of the code, meaning the source code appears backwards, with the last characters at the start, and the first characters at the end.



Backwards code: not very useful



Next, I tried about using a </a></code> but that also didn’t work, as <strong>textareas can only contain plain text</strong>. In other words, we’re unable to style the content that’s entered. A <code>textarea</code> seems to be the only way to edit the text without unwanted bugs — it just doesn’t let Prism.js do its thing.</p>



<p>Prism.js works a lot better when the source code is wrapped in a typical <code><pre><code></code> tag combo — it’s only missing the editable part of the equation.</p>



<p>So, neither seems to work by themselves. But, I thought, <em>why not both?</em></p>


<h3 id="h-the-solution">The solution</h3>


<p>I added both a syntax-highlighted <code><pre><code></code> <em>and</em> a <code>textarea</code> to the page, and made the <code>innerText</code> content of <code><pre><code></code> change <code>oninput</code>, using a JavaScript function. I also added an <code>aria-hidden</code> attribute to the <code><pre><code></code> result so that screen readers would only read what is entered into the <code><textarea></code> instead of being read aloud twice.</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><textarea id="editing" oninput="update(this.value);">

  




function update(text) {
  let result_element = document.querySelector("#highlighting-content");
  // Update code
  result_element.innerText = text;
  // Syntax Highlight
  Prism.highlightElement(result_element);
}



Now it’s editable and highlighted!



Now, when the textarea is edited — as in, a pressed key on the keyboard comes back up — the syntax-highlighted code changes. There are a few bugs we’ll get to, but I want to focus first on making it look like you are directly editing the syntax-highlighted element, rather than a separate textarea.


Making it “feel” like a code editor


The idea is to visibly merge the elements together so it looks like we’re interacting with one element when there are actually two elements at work. We can add some CSS that basically allows the </code> and the <code><pre><code></code> elements to be sized and spaced consistently.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">#editing, #highlighting {
  /* Both elements need the same text and space styling so they are directly on top of each other */
  margin: 10px;
  padding: 10px;
  border: 0;
  width: calc(100% - 32px);
  height: 150px;
}

#editing, #highlighting, #highlighting * {
  /* Also add text styles to highlighting tokens */
  font-size: 15pt;
  font-family: monospace;
  line-height: 20pt;
}</code></pre>



<p>Then we want to position them right on top of each other:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">#editing, #highlighting {
  position: absolute;
  top: 0;
  left: 0;
}</code></pre>



<p>From there, <code>z-index</code> allows the <code>textarea</code> to stack in front the highlighted result:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* Move the textarea in front of the result */
#editing {
  z-index: 1;
}

#highlighting {
  z-index: 0;
}</code></pre>



<p>If we stop here, we’ll see our first bug. It doesn’t look like Prism.js is highlighting the syntax, but that is only because the <code>textarea</code> is covering up the result.</p>



<figure class="wp-block-image size-full ticss-529012e2"><figcaption>Where has the highlighting gone? (Clue: It’s hiding in the background.)</figcaption></figure>



<p>We can fix this with CSS! We’ll make the <code><textarea></code> completely transparent <em>except</em> the caret (cursor):</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* Make textarea almost completely transparent */
#editing {
  color: transparent;
  background: transparent;
  caret-color: white; /* Or choose your favorite color */
}</code></pre>



<p>Ah, much better!</p>



<figure class="wp-block-image size-full"><figcaption>Where will this link take you? You decide.</figcaption></figure>


<h3 id="h-more-fixing">More fixing!</h3>


<p>Once I got this far, I played around with the editor a bit and was able to find a few more things that needed fixing. The good thing is that all of the issues are quite easy to fix using JavaScript, CSS, or even HTML.</p>


<h4 id="h-remove-native-spell-checking">Remove native spell checking</h4>


<p>We’re making a code editor, and code has lots of words and attributes that a browser’s native spell checker will think are misspellings.</p>



<figure class="wp-block-image size-full"></figure>



<p>Spell checking isn’t a bad thing; it’s just unhelpful in this situation. Is something marked incorrect because it is incorrectly spelled or because the code is invalid? It’s tough to tell. To fix this, all we need is to set the <code>spellcheck</code> attribute on the <code><textarea></code> to <code>false</code>:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><textarea id="editing" spellcheck="false" ...></code></pre>


<h4 id="h-handling-new-lines">Handling new lines</h4>


<p>Turns out that <code>innerText</code> doesn’t support newlines (<code>\n</code>).</p>



<figure class="wp-block-image size-full"><figcaption>Even though “World!” should be on a new line, the syntax highlighted section displays it on the same line.</figcaption></figure>



<p>The <code>update</code> function needs to be edited. Instead of using <code>innerText</code>, we can use <code>innerHTML</code>, replacing the open bracket character (<code><</code>) with <code><</code> and replace the ampersand character (<code>&</code>) with <code>&</code> to stop HTML escapes from being evaluated. This prevents new HTML tags from being created, allowing the actual source code displays instead of the browser attempting to render the code.</p>



<pre rel="JavaScript" class="wp-block-csstricks-code-block language-javascript" data-line=""><code markup="tt">result_element.innerHTML = text.replace(new RegExp("&", "g"), "&").replace(new RegExp("<", "g"), "<"); /* Global RegExp */</code></pre>



<figure class="wp-block-image size-full"></figure>


<h4 id="h-scrolling-and-resizing">Scrolling and resizing</h4>


<figure class="wp-block-image size-full"></figure>



<p>Here’s another thing: the highlighted code cannot scroll while the editing is taking place. And when the textarea is scrolled, the highlighted code does not scroll with it.</p>



<p>First, let’s make sure that both the <code>textarea</code> and result support scrolling:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* Can be scrolled */
#editing, #highlighting {
  overflow: auto;
  white-space: nowrap; /* Allows textarea to scroll horizontally */
}</code></pre>



<p>Then, to make sure that the result scrolls <em>with</em> the textarea, we’ll update the HTML and JavaScript like this:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><textarea id="editing" oninput="update(this.value); sync_scroll(this);" onscroll="sync_scroll(this);">



function sync_scroll(element) {
  /* Scroll result to scroll coords of event - sync with textarea */
  let result_element = document.querySelector("#highlighting");
  // Get and set x and y
  result_element.scrollTop = element.scrollTop;
  result_element.scrollLeft = element.scrollLeft;
}



Some browsers also allow a textarea to be resized, but this means that the textarea and result could become different sizes. Can CSS fix this? Of course it can. We’ll simply disable resizing:



/* No resize on textarea */
#editing {
  resize: none;
}


Final newlines






Thanks to this comment for pointing out this bug.



Now the scrolling is almost always synchronized, but there is still one case where it still doesn’t work. When the user creates a new line, the cursor and the textarea’s text are temporarily in the wrong position before any text is entered on the new line. This is because the 
 block ignores an empty final line for aesthetic reasons. Because this is for a functional code input, rather than a piece of displayed code, the empty final line needs to be shown. This is done by giving the final line content so it is no longer empty, with a few lines of JavaScript added to the update function. I have used a space character because it is invisible to the user.



function update(text) {
  let result_element = document.querySelector("#highlighting-content");
  // Handle final newlines (see article)
  if(text[text.length-1] == "\n") { // If the last character is a newline character
    text += " "; // Add a placeholder space character to the final line 
  }
  // Update code
  result_element.innerHTML = text.replace(new RegExp("&", "g"), "&").replace(new RegExp("<", "g"), "<"); /* Global RegExp */
  // Syntax Highlight
  Prism.highlightElement(result_element);
}


Indenting lines


One of the trickier things to adjust is how to handle line indentations in the result. The way the editor is currently set up, indenting lines with spaces works fine. But, if you’re more into tabs than spaces, you may have noticed that those aren’t working as expected.



JavaScript can be used to make the Tab key properly work. I have added comments to make it clear what is happening in the function.







function check_tab(element, event) {
  let code = element.value;
  if(event.key == "Tab") {
    /* Tab key pressed */
    event.preventDefault(); // stop normal
    let before_tab = code.slice(0, element.selectionStart); // text before tab
    let after_tab = code.slice(element.selectionEnd, element.value.length); // text after tab
    let cursor_pos = element.selectionEnd + 1; // where cursor moves after tab - moving forward by 1 char to after tab
    element.value = before_tab + "\t" + after_tab; // add tab char
    // move cursor
    element.selectionStart = cursor_pos;
    element.selectionEnd = cursor_pos;
    update(element.value); // Update text to include indent
  }
}



To make sure the Tab characters are the same size in both the </code> and the syntax-highlighted code block, edit the <code>CSS</code> to include <a href="https://css-tricks.com/almanac/properties/t/tab-size/">the <code>tab-size</code> property</a>:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line="4"><code markup="tt">#editing, #highlighting, #highlighting * {
  /* Also add text styles to highlighing tokens */
  [...]
  tab-size: 2;
}</code></pre>


<h3 id="h-the-final-result">The final result</h3>


<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper">CodePen Embed Fallback</iframe></div>



<p>Not too crazy, right? All we have are <code><textarea></code>, <code><pre></code> and <code><code></code> elements in the HTML, a new lines of CSS that stack them together, and a syntax highlighting library to format what’s entered. And what I like best about this is that we’re working with normal, semantic HTML elements, leveraging native attributes to get the behavior we want, leaning on CSS to create the illusion that we’re only interacting with one element, then reaching for JavaScript to solve some edge cases.</p>



<p>While I used Prism.js for syntax highlighting, this technique will work with others. It would even work with a syntax highlighter you create yourself, if you want it to. I hope this becomes useful, and can be used in many places, whether it’s a <abbr title="What you see is what you get">WYSIWYG</abbr> editor for a CMS, or even a forms where the ability to enter source code is a requirement like a front-end job application or perhaps a quiz. It is a<code><textarea></code>, after all, so it’s capable of being used in any form — you can even add a <code>placeholder</code> if you need to!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/creating-an-editable-textarea-that-supports-syntax-highlighted-code/">Creating an Editable Textarea That Supports Syntax-Highlighted Code</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>Building a Scalable CSS Architecture With BEM and Utility Classes</h1>
<p>Sebastiano Guerriero — Tue, 21 Apr 2020 14:43:29 +0000</p>

<p>Maintaining a large-scale CSS project is hard. Over the years, we’ve witnessed different approaches aimed at easing the process of writing scalable CSS. In the end, we all try to meet the following two goals:</p>



<ol><li><strong>Efficiency</strong>: we want to reduce the time spent thinking about how things should be done and increase the time doing things.</li><li><strong>Consistency</strong>: we want to make sure all developers are on the same page.</li></ol>



<p>For the past year and a half, I’ve been working on a <a href="https://codyhouse.co/ds/components" rel="noopener">component library</a> and a front-end framework called <a href="https://codyhouse.co/ds/docs/framework" rel="noopener">CodyFrame</a>. We currently have 220+ components. These components are not isolated modules: they’re reusable patterns, often merged into each other to create complex templates.</p>



<p>The challenges of this project have forced our team to develop a way of building scalable CSS architectures. This method relies on <strong>CSS globals, BEM, and utility classes</strong>.</p>



<span id="more-306134"></span>



<p>I’m happy to share it! 👇</p>


<h3 id="h-css-globals-in-30-seconds">CSS Globals in 30 seconds</h3>


<p>Globals are CSS files containing rules that apply crosswise to all components (e.g., spacing scale, typography scale, colors, etc.). Globals use tokens to keep the design consistent across all components and reduce the size of their CSS.</p>



<p>Here’s an example of typography global rules:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* Typography | Global */
:root {
  /* body font size */
  --text-base-size: 1em;
 
  /* type scale */
  --text-scale-ratio: 1.2;
  --text-xs: calc((--text-base-size / var(--text-scale-ratio)) / var(--text-scale-ratio));
  --text-sm: calc(var(--text-xs) * var(--text-scale-ratio));
  --text-md: calc(var(--text-sm) * var(--text-scale-ratio) * var(--text-scale-ratio));
  --text-lg: calc(var(--text-md) * var(--text-scale-ratio));
  --text-xl: calc(var(--text-lg) * var(--text-scale-ratio));
  --text-xxl: calc(var(--text-xl) * var(--text-scale-ratio));
}
 
@media (min-width: 64rem) { /* responsive decision applied to all text elements */
  :root {
    --text-base-size: 1.25em;
    --text-scale-ratio: 1.25;
  }
}
 
h1, .text-xxl   { font-size: var(--text-xxl, 2.074em); }
h2, .text-xl    { font-size: var(--text-xl, 1.728em); }
h3, .text-lg    { font-size: var(--text-lg, 1.44em); }
h4, .text-md    { font-size: var(--text-md, 1.2em); }
.text-base      { font-size: --text-base-size; }
small, .text-sm { font-size: var(--text-sm, 0.833em); }
.text-xs        { font-size: var(--text-xs, 0.694em); }</code></pre>


<h3 id="h-bem-in-30-seconds">BEM in 30 seconds</h3>


<p><a href="https://css-tricks.com/bem-101/">BEM</a> (Blocks, Elements, Modifiers) is a naming methodology aimed at creating reusable components.</p>



<p>Here’s an example:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><header class="header">
  <a href="#0" class="header__logo"><!-- ... --></a>
  <nav class="header__nav">
    <ul>
      <li><a href="#0" class="header__link header__link--active">Homepage</a></li>
      <li><a href="#0" class="header__link">About</a></li>
      <li><a href="#0" class="header__link">Contact</a></li>
    </ul>
  </nav>
</header></code></pre>



<ul><li>A <strong>block</strong> is a reusable component</li><li>An <strong>element</strong> is a child of the block (e.g., <code>.block__element</code>)</li><li>A <strong>modifier</strong> is a variation of a block/element (e.g., <code>.block--modifier</code>, .<code>block__element--modifier</code>).</li></ul>


<h3 id="h-utility-classes-in-30-seconds">Utility classes in 30 seconds</h3>


<p>A utility class is a CSS class meant to do only one thing. For example:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><section class="padding-md">
  <h1>Title</h1>
  <p>Lorem ipsum dolor sit amet consectetur adipisicing elit.</p>
</section>
 
<style>
  .padding-sm { padding: 0.75em; }
  .padding-md { padding: 1.25em; }
  .padding-lg { padding: 2em; }
</style></code></pre>



<p>You can potentially build entire components out of utility classes:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><article class="padding-md bg radius-md shadow-md">
  <h1 class="text-lg color-contrast-higher">Title</h1>
  <p class="text-sm color-contrast-medium">Lorem ipsum dolor sit amet consectetur adipisicing elit.</p>
</article></code></pre>



<p>You can connect utility classes to CSS globals:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* Spacing | Global */
:root {
  --space-unit: 1em;
  --space-xs:   calc(0.5 * var(--space-unit));
  --space-sm:   calc(0.75 * var(--space-unit));
  --space-md:   calc(1.25 * var(--space-unit));
  --space-lg:   calc(2 * var(--space-unit));
  --space-xl:   calc(3.25 * var(--space-unit));
}

/* responsive rule affecting all spacing variables */
@media (min-width: 64rem) {
  :root {
    --space-unit:  1.25em; /* 👇 this responsive decision affects all margins and paddings */
  }
} 
/* margin and padding util classes - apply spacing variables */
.margin-xs { margin: var(--space-xs); }
.margin-sm { margin: var(--space-sm); }
.margin-md { margin: var(--space-md); }
.margin-lg { margin: var(--space-lg); }
.margin-xl { margin: var(--space-xl); }

.padding-xs { padding: var(--space-xs); }
.padding-sm { padding: var(--space-sm); }
.padding-md { padding: var(--space-md); }
.padding-lg { padding: var(--space-lg); }
.padding-xl { padding: var(--space-xl); }</code></pre>


<h3 id="h-a-real-life-example">A real-life example</h3>


<p>Explaining a methodology using basic examples doesn’t bring up the real issues nor the advantages of the method itself.</p>



<p>Let’s build something together! </p>



<p>We’ll create a gallery of card elements. First, we’ll do it using only the BEM approach, and we’ll point out the issues you may face by going BEM only. Next, we’ll see how Globals reduce the size of your CSS. Finally, we’ll make the component customizable introducing utility classes to the mix.</p>



<p>Here’s a look at the final result:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper">CodePen Embed Fallback</iframe></div>



<p>Let’s start this experiment by creating the gallery using only BEM:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><div class="grid">
  <article class="card">
    <a class="card__link" href="#0">
      <figure>
        
      </figure>
 
      <div class="card__content">
        <h1 class="card__title-wrapper"><span class="card__title">Title of the card</span></h1>
 
        <p class="card__description">Lorem ipsum dolor sit amet consectetur adipisicing elit. Tempore, totam?</p>
      </div>
 
      <div class="card__icon-wrapper" aria-hidden="true">
        <svg class="card__icon" viewBox="0 0 24 24"><!-- icon --></svg>
      </div>
    </a>
  </article>
 
  <article class="card"><!-- card --></article>
  <article class="card"><!-- card --></article>
  <article class="card"><!-- card --></article>
</div></code></pre>



<p>In this example, we have two components: <code>.grid</code> and <code>.card</code>. The first one is used to create the gallery layout. The second one is the card component.</p>



<p>First of all, let me point out the main advantages of using BEM: <strong>low specificity</strong> and <strong>scope</strong>.</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* without BEM */
.grid {}
.card {}
.card > a {}
.card img {}
.card-content {}
.card .title {}
.card .description {}
 
/* with BEM */
.grid {}
.card {}
.card__link {}
.card__img {}
.card__content {}
.card__title {}
.card__description {}</code></pre>



<p>If you don’t use BEM (or a similar naming method), you end up creating inheritance relationships (<code>.card > a</code>).</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* without BEM */
.card > a.active {} /* high specificity */
 
/* without BEM, when things go really bad */
div.container main .card.is-featured > a.active {} /* good luck with that 😦 */
 
/* with BEM */
.card__link--active {} /* low specificity */</code></pre>



<p>Dealing with inheritance and specificity in big projects is painful. That feeling when your CSS doesn’t seem to be working, and you find out it’s been overwritten by another class 😡! BEM, on the other hand, creates some kind of scope for your components and keeps specificity low.</p>



<p>But… <strong>there are two main downsides of using only BEM:</strong></p>



<ol><li>Naming too many things is frustrating</li><li>Minor customizations are not easy to do or maintain</li></ol>



<p>In our example, to stylize the components, we’ve created the following classes:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.grid {}
.card {}
.card__link {}
.card__img {}
.card__content {}
.card__title-wrapper {}
.card__title {}
.card__description {}
.card__icon-wrapper {}
.card__icon {}</code></pre>



<p>The number of classes is not the issue. The issue is coming up with so many meaningful names (and having all your teammates use the same naming criteria).<br>
</p>



<p>For example, imagine you have to modify the card component by including an additional, smaller paragraph:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><div class="card__content">
  <h1 class="card__title-wrapper"><span class="card__title">Title of the card</span></h1>
  <p class="card__description">Lorem ipsum dolor...</p>
  <p class="card__description card__description--small">Lorem ipsum dolor...</p> <!-- 👈 -->
</div></code></pre>



<p>How do you call it? You could consider it a variation of the <code>.card__description</code> element and go for <code>.card__description .card__description--small</code>. Or, you could create a new element, something like <code>.card__small, .card__small-p</code>, or <code>.card__tag</code>. See where I’m going? No one wants to spend time thinking about class names. <strong>BEM is great as long as you don’t have to name too many things</strong>.</p>



<p>The second issue is dealing with minor customizations. For example, imagine you have to create a variation of the card component where the text is center-aligned.</p>



<p>You’ll probably do something like this:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><div class="card__content card__content--center"> <!-- 👈 -->
  <h1 class="card__title-wrapper"><span class="card__title">Title of the card</span></h1>
  <p class="card__description">Lorem ipsum dolor sit amet consectetur adipisicing elit. Tempore, totam?</p>
</div>
 
<style>
  .card__content--center { text-align: center; }
</style></code></pre>



<p>One of your teammates, working on another component (<code>.banner</code>), is facing the same problem. They create a variation for their component as well:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><div class="banner banner--text-center"></div>
 
<style>
  .banner--text-center { text-align: center; }
</style></code></pre>



<p>Now imagine you have to include the banner component into a page. You need the variation where the text is aligned in the center. Without checking the CSS of the banner component, you may instinctively write something like <code>banner banner--center</code> in your HTML, because you always use <code>--center</code> when you create variations where the text is center-aligned. Not working! Your only option is to open the CSS file of the banner component, inspect the code, and find out what class should be applied to align the text in the center.</p>



<p>How long would it take, 5 minutes? Multiply 5 minutes by all the times this happens in a day, to you and all your teammates, and you realize how much time is wasted. Plus, adding new classes that do the same thing contributes to bloating your CSS.</p>


<h3 id="h-css-globals-and-utility-classes-to-the-rescue">CSS Globals and utility classes to the rescue</h3>


<p>The first advantage of setting global styles is having a set of CSS rules that apply to all the components.</p>



<p>For example, if we set responsive rules in the spacing and typography globals, these rules will affect the grid and card components as well. In CodyFrame, we increase the body font size at a specific breakpoint; because we use “em” units for all margins and paddings, the whole spacing system is updated at once generating a <a href="https://codyhouse.co/ds/docs/framework/typography%23type-scale" rel="noopener">cascade effect</a>.</p>



<figure class="wp-block-image size-large"><figcaption>Spacing and typography responsive rules — no media queries on a component level </figcaption></figure>



<p>As a consequence, in most cases, you won’t need to use media queries to increase the font size or the values of margins and paddings!</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">/* without globals */
.card { padding: 1em; }
 
@media (min-width: 48rem) {
  .card { padding: 2em; }
  .card__content { font-size: 1.25em; }
}
 
/* with globals (responsive rules intrinsically applied) */
.card { padding: var(--space-md); }</code></pre>



<p>Not just that! You can use the globals to store behavioral components that can be combined with all other components. For example, in CodyFrame, we define a <a href="https://codyhouse.co/ds/docs/framework/typography%23text-component" rel="noopener"><code>.text-component</code></a> class that is used as a “text wrapper.” It takes care of line height, vertical spacing, basic styling, and other things.</p>



<p>If we go back to our card example, the <code>.card__content</code> element could be replaced with the following:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><!-- without globals -->
<div class="card__content">
  <h1 class="card__title-wrapper"><span class="card__title">Title of the card</span></h1>
  <p class="card__description">Lorem ipsum dolor sit amet consectetur adipisicing elit. Tempore, totam?</p>
</div>
 
<!-- with globals -->
<div class="text-component">
  <h1 class="text-lg"><span class="card__title">Title of the card</span></h1>
  <p>Lorem ipsum dolor sit amet consectetur adipisicing elit. Tempore, totam?</p>
</div></code></pre>



<p>The text component will take care of the text formatting, and make it consistent across all the text blocks in your project. Plus, we’ve already eliminated a couple of BEM classes.</p>


<h3 id="h-finally-let-s-introduce-the-utility-classes-to-the-mix">Finally, let’s introduce the utility classes to the mix!</h3>


<p>Utility classes are particularly useful if you want the ability to customize the component later on without having to check its CSS.</p>



<p>Here’s how the structure of the card component changes if we swap some BEM classes with utility classes:</p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><article class="card radius-lg">
  <a href="#0" class="block color-inherit text-decoration-none">
    <figure>
      
    </figure>
 
    <div class="text-component padding-md">
      <h1 class="text-lg"><span class="card__title">Title of the card</span></h1>
      <p class="color-contrast-medium">Lorem ipsum dolor sit amet consectetur adipisicing elit. Tempore, totam?</p>
    </div>
 
    <div class="card__icon-wrapper" aria-hidden="true">
      <svg class="icon icon--sm color-white" viewBox="0 0 24 24"><!-- icon --></svg>
    </div>
  </a>
</article></code></pre>



<p>The number of BEM (component) classes has shrunk from 9 to 3:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.card {}
.card__title {}
.card__icon-wrapper {}</code></pre>



<p>That means you won’t deal much with naming things. That said, we can’t avoid the naming issue entirely: even if you create Vue/React/SomeOtherFramework components out of utility classes, you still have to name the components.</p>



<p>All the other BEM classes have been replaced by utility classes. What if you have to make a card variation with a bigger title? Replace text-lg with text-xl. What if you want to change the icon color? Replace color-white with color-primary. How about aligning the text in the center? Add text-center to the text-component element. Less time thinking, more time doing!</p>


<h3 id="h-why-don-t-we-just-use-utility-classes">Why don’t we just use utility classes?</h3>


<p>Utility classes speed-up the design process and make it easier to customize things. So why don’t we forget about BEM and use only utility classes? Two main reasons:</p>


<h4 id="h-by-using-bem-together-with-utility-classes-the-html-is-easier-to-read-and-customize">By using BEM together with utility classes, the HTML is easier to read and customize.</h4>


<p>Use BEM for:</p>



<ul><li>DRY-ing the HTML from the CSS you don’t plan on customizing (e.g., behavioral CSS-like transitions, positioning, hover/focus effects),</li><li>advanced animations/effects.</li></ul>



<p>Use utility classes for:</p>



<ul><li>the “frequently-customized” properties, often used to create component variations (like padding, margin, text-alignment, etc.),</li><li>elements that are hard to identify with a new, meaningful class name (e.g., you need a parent element with a <code>position: relative</code> → create <code><div class="position-relative"><div class="my-component"></div></div></code>).</li></ul>



<p>Example: </p>



<pre rel="HTML" class="wp-block-csstricks-code-block language-markup" data-line=""><code markup="tt"><!-- use only Utility classes -->
<article class="position-relative overflow-hidden bg radius-lg transition-all duration-300 hover:shadow-md col-6@sm col-4@md">
  <!-- card content -->
</article>
 
<!-- use BEM + Utility classes -->
<article class="card radius-lg col-6@sm col-4@md">
  <!-- card content -->
</article></code></pre>



<p>For these reasons, we suggest that you <em>don’t</em> add the !important rule to your utility classes. Using utility classes doesn’t need to be like using a hammer. Do you think it would be beneficial to access and modify a CSS property in the HTML? Use a utility class. Do you need a bunch of rules that won’t need editing? Write them in your CSS. This process doesn’t need to be perfect the first time you do it: you can tweak the component later on if required. It may sound laborious “having to decide” but it’s quite straightforward when you put it to practice.</p>


<h4 id="h-utility-classes-are-not-your-best-ally-when-it-comes-to-creating-unique-effects-animations">Utility classes are not your best ally when it comes to creating unique effects/animations.</h4>


<p>Think about working with pseudo-elements, or crafting unique motion effects that require custom bezier curves. For those, you still need to open your CSS file.</p>



<p>Consider, for example, the animated background effect of the card we’ve designed. How hard would it be to create such an effect using utility classes?</p>



<p>The same goes for the icon animation, which requires animation keyframes to work:</p>



<pre rel="CSS" class="wp-block-csstricks-code-block language-css" data-line=""><code markup="tt">.card:hover .card__title {
  background-size: 100% 100%;
}
 
.card:hover .card__icon-wrapper .icon {
  animation: card-icon-animation .3s;
}
 
.card__title {
  background-image: linear-gradient(transparent 50%, alpha(var(--color-primary), 0.2) 50%);
  background-repeat: no-repeat;
  background-position: left center;
  background-size: 0% 100%;
  transition: background .3s;
}
 
.card__icon-wrapper {
  position: absolute;
  top: 0;
  right: 0;
  width: 3em;
  height: 3em;
  background-color: alpha(var(--color-black), 0.85);
  border-bottom-left-radius: var(--radius-lg);
  display: flex;
  justify-content: center;
  align-items: center;
}
 
@keyframes card-icon-animation {
  0%, 100% {
    opacity: 1;
    transform: translateX(0%);
  }
  50% {
    opacity: 0;
    transform: translateX(100%);
  }
  51% {
    opacity: 0;
    transform: translateX(-100%);
  }
}</code></pre>


<h3 id="h-final-result">Final result</h3>


<p>Here’s the final version of the cards gallery. It also includes grid utility classes to customize the layout.</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper">CodePen Embed Fallback</iframe></div>


<h3 id="h-file-structure">File structure</h3>


<p>Here’s how the structure of a project built using the method described in this article would look like:</p>



<pre rel="" class="wp-block-csstricks-code-block language-none" data-line=""><code markup="tt">project/
└── main/
    ├── assets/
    │   ├── css/
    │   │   ├── components/
    │   │   │   ├── _card.scss
    │   │   │   ├── _footer.scss
    │   │   │   └── _header.scss
    │   │   ├── globals/
    │   │   │   ├── _accessibility.scss
    │   │   │   ├── _breakpoints.scss
    │   │   │   ├── _buttons.scss
    │   │   │   ├── _colors.scss
    │   │   │   ├── _forms.scss
    │   │   │   ├── _grid-layout.scss
    │   │   │   ├── _icons.scss
    │   │   │   ├── _reset.scss
    │   │   │   ├── _spacing.scss
    │   │   │   ├── _typography.scss
    │   │   │   ├── _util.scss
    │   │   │   ├── _visibility.scss
    │   │   │   └── _z-index.scss
    │   │   ├── _globals.scss
    │   │   ├── style.css
    │   │   └── style.scss
    │   └── js/
    │       ├── components/
    │       │   └── _header.js
    │       └── util.js
    └── index.html</code></pre>



<p>You can store the CSS (or SCSS) of each component into a separate file (and, optionally, use PostCSS plugins to compile each new <code>/component/componentName.css</code> file into <code>style.css</code>). Feel free to organize the globals as you prefer; you could also create a single <code>globals.css</code> file and avoid separating the globals in different files.</p>


<h3 id="h-conclusion">Conclusion</h3>


<p>Working on large-scale projects requires a solid architecture if you want to open your files months later and don’t get lost. There are many methods out there that tackle this issue (CSS-in-JS, utility-first, atomic design, etc.).</p>



<p>The method I’ve shared with you today relies on creating crosswise rules (globals), using utility classes for rapid development, and BEM for modular (behavioral) classes.</p>



<p>You can learn in more detail about this method on <a href="https://codyhouse.co/ds/get-started" rel="noopener">CodyHouse</a>. Any feedback is welcome!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/building-a-scalable-css-architecture-with-bem-and-utility-classes/">Building a Scalable CSS Architecture With BEM and Utility Classes</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>Why JavaScript is Eating HTML</h1>
<p>Mike Turley — Thu, 13 Feb 2020 15:13:56 +0000</p>

<p>Web development is always changing. One trend in particular has become very popular lately, and it fundamentally goes against the conventional wisdom about how a web page should be made. It is exciting for some but frustrating for others, and the reasons for both are difficult to explain.</p>



<p>A web page is traditionally made up of three separate parts with separate responsibilities: <strong>HTML code</strong> defines the structure and meaning of the content on a page, <strong>CSS code</strong> defines its appearance, and <strong>JavaScript code</strong> defines its behavior. On teams with dedicated designers, HTML/CSS developers and JavaScript developers, this <a href="https://en.wikipedia.org/wiki/Separation_of_concerns" rel="noopener">separation of concerns</a> aligns nicely with job roles: Designers determine the visuals and user interactions on a page, HTML and CSS developers reproduce those visuals in a web browser, and JavaScript developers add the user interaction to tie it all together and “make it work.” People can work on one piece without getting involved with all three.</p>



<p>In recent years, JavaScript developers have realized that by defining a page’s structure in JavaScript instead of in HTML (using frameworks such as <a href="https://reactjs.org/" rel="noopener">React</a>), they can simplify the development and maintenance of user interaction code that is otherwise much more complex to build. Of course, when you tell someone that the HTML they wrote needs to be chopped up and mixed in with JavaScript they don’t know anything about, they can (understandably) become frustrated and start asking what the heck we’re getting out of this.</p>



<p>As a JavaScript developer on a cross-functional team, I get this question occasionally and I often have trouble answering it. All of the materials I’ve found on this topic are written for an audience that is already familiar with JavaScript — which is not terribly useful to those who focus on HTML and CSS. But this <strong>HTML-in-JS</strong> pattern (or something else that provides the same benefits) will likely be around for a while, so I think it’s an important thing that everyone involved in web development should understand.</p>



<span id="more-302876"></span>



<p>This article will include code examples for those interested, but my goal is to explain this concept in a way that can be understood without them.</p>


<h3 id="background-html-css-and-javascript">Background: HTML, CSS, and JavaScript</h3>


<p>To broaden the audience of this article as much as possible, I want to give a quick background on the types of code involved in creating a web page and their traditional roles. If you have experience with these, you can skip ahead.</p>


<h4 id="html-is-for-structure-and-semantic-meaning">HTML is for structure and semantic meaning</h4>


<p>HTML (HyperText Markup Language) code defines the structure and meaning of the content on a page. For example, this article’s HTML contains the text you’re reading right now, the fact that it is in a paragraph, and the fact that it comes after a heading and before a CodePen.</p>



<p>Let’s say we want to build a simple shopping list app. We might start with some HTML like this:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper">CodePen Embed Fallback</iframe></div>



<p>We can save this code in a file, open it in a web browser, and the browser will display the rendered result. As you can see, the HTML code in this example represents a section of a page that contains a heading reading “Shopping List (2 items),” a text input box, a button reading “Add Item,” and a list with two items reading “Eggs” and “Butter.” In a traditional website, a user would navigate to an address in their web browser, then the browser would request this HTML from a server, load it and display it. If there are already items in the list, the server could deliver HTML with the items already in place, like they are in this example.</p>



<p>Try to type something in the input box and click the “Add Item” button. You’ll notice nothing happens. The button isn’t connected to any code that can change the HTML, and the HTML can’t change itself. We’ll get to that in a moment.</p>


<h4 id="css-is-for-appearance">CSS is for appearance</h4>


<p>CSS (Cascading Style Sheets) code defines the appearance of a page. For example, this article’s CSS contains the font, spacing, and color of the text you’re reading.</p>



<p>You may have noticed that our shopping list example looks very plain. There is no way for HTML to specify things like spacing, font sizes, and colors. This is where CSS (Cascading Style Sheets) comes in. On the same page as the HTML above, we could add CSS code to style things up a bit:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper">CodePen Embed Fallback</iframe></div>



<p>As you can see, this CSS changed the font sizes and weights and gave the section a nice background color (designers, please don’t @ me; I know this is still ugly). A developer can write style rules like these and they will be applied consistently to any HTML structure: if we add more <code><section></code>, <code><button></code> or <code><ul></code> elements to this page, they will have the same font changes applied.</p>



<p>The button still doesn’t do anything, though: that’s where JavaScript comes in.</p>


<h4 id="javascript-is-for-behavior">JavaScript is for behavior</h4>


<p>JavaScript code defines the behavior of interactive or dynamic elements on a page. For example, the embedded CodePen examples in this article are powered by JavaScript.</p>



<p>Without JavaScript, to make the Add Item button in our example work would require us to use special HTML to make it submit data back to the server (<code><form action="..."></code>, if you’re curious). Then the browser would discard the entire page and reload an updated version of the entire HTML file. If this shopping list was part of a larger page, anything else the user was doing would be lost. Scrolled down? You’re back at the top. Watching a video? It starts over. This is how all web applications worked for a long time: any time a user interacted with a webpage, it was as if they closed their web browser and opened it again. That’s not a big deal for this simple example, but for a large complex page which could take a while to load, it’s not efficient for either the browser or the server.</p>



<p><strong>If we want anything to change on a webpage without reloading the entire page, we need JavaScript</strong> (<a href="https://www.seguetech.com/java-vs-javascript-difference/" rel="noopener">not to be confused with Java, which is an entirely different language</a>… don’t get me started). Let’s try adding some:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper">CodePen Embed Fallback</iframe></div>



<p>Now when we type some text in the box and click the “Add Item” button, our new item is added to the list and the item count at the top is updated! In a real app, we would also add some code to send the new item to the server in the background so that it will still show up the next time we load the page.</p>



<p>Separating JavaScript from the HTML and CSS makes sense in this simple example. Traditionally, even more complicated interactions would be added this way: HTML is loaded and displayed, and JavaScript runs afterwards to add things to it and change it. As things get more complex, however, we start needing to keep better track of things in our JavaScript.</p>



<p>If we were to keep building this shopping list app, next we’d probably add buttons for editing or removing items from the list. Let’s say we write the JavaScript for a button that removes an item, but we forget to add the code that updates the item total at the top of the page. Suddenly we have a bug: after a user removes an item, the total on the page won’t match the list! Once we notice the bug, we fix it by adding that same <code>totalText.innerHTML</code> line from our “Add Item” code to the “Remove Item” code. Now we have the same code duplicated in more than one place. Later on, let’s say we want to change that code so that instead of “(2 items)” at the top of the page it reads “Items: 2.” We’ll have to make sure we update it in all three places: in the HTML, in the JavaScript for the “Add Item” button, and in the JavaScript for the “Remove Item” button. If we don’t, we’ll have another bug where that text abruptly changes after a user interaction.</p>



<p>In this simple example, we can already see how quickly these things can get messy. There are ways to organize our JavaScript to make this kind of problem easier to deal with, but as things continue to get more complex, we’ll need to keep restructuring and rewriting things to keep up. As long as HTML and JavaScript are kept separate, a lot of effort can be required to make sure everything is kept in sync between them. That’s one of the reasons why new JavaScript frameworks, like React, have gained traction: they are designed to show the relationships between things like HTML and JavaScript. To understand how that works, we first need to understand just a teeny bit of computer science.</p>


<h3 id="two-kinds-of-programming">Two kinds of programming</h3>


<p>The key concept to understand here involves the distinction between two common programming styles. (There are other programming styles, of course, but we’re only dealing with two of them here.) Most programming languages lend themselves to one or the other of these, and some can be used in both ways. It’s important to grasp both in order to understand the main benefit of HTML-in-JS from a JavaScript developer’s perspective.</p>



<ul><li><a href="https://en.wikipedia.org/wiki/Imperative_programming" rel="noopener"><strong>Imperative programming</strong></a>: The word “imperative” here implies commanding a computer to do something. A line of imperative code is a lot like <a href="https://www.learngrammar.net/a/examples-of-imperative-sentence" rel="noopener">an imperative sentence</a> in English: it gives the computer a specific instruction to follow. In imperative programming, we must tell the computer exactly <em>how</em> to do every little thing we need it to do. In web development, this is starting to be considered “the old way” of doing things and it’s what you do with vanilla JavaScript, or libraries like jQuery. The JavaScript in my shopping list example above is imperative code.<ul><li>Imperative: “Do X, then do Y, then do Z”.</li><li>Example: When the user selects this element, add the <code>.selected</code> class to it; and when the user de-selects it, remove the <code>.selected</code> class from it.</li></ul></li><li><a href="https://en.wikipedia.org/wiki/Declarative_programming" rel="noopener"><strong>Declarative programming</strong></a>: This is a more abstract layer above imperative programming. Instead of giving the computer instructions, we instead “declare” <em>what</em> we want the results to be after the computer does something. Our tools (e.g. React) figure out the <em>how</em> for us automatically. These tools are built with imperative code on the inside that we don’t have to pay attention to from the outside.<ul><li>Declarative: “The result should be XYZ. Do whatever you need to do to make that happen.”</li><li>Example: This element has the <code>.selected</code> class if the user has selected it.</li></ul></li></ul>


<h4 id="html-is-a-declarative-language">HTML is a declarative language</h4>


<p>Forget about JavaScript for a moment. Here’s an important fact: <strong>HTML on its own is a declarative language</strong>. In an HTML file, you can <strong>declare</strong> something like:</p>



<pre rel="HTML" class="language-markup" data-line="" class="wp-block-csstricks-code-block"><code markup="tt"><section>
  <h1>Hello</h1>
  <p>My name is Mike.</p>
</section></code></pre>



<p>When a web browser reads this HTML, it will figure out these <strong>imperative steps</strong> for you and execute them:</p>



<ol><li>Create a section element</li><li>Create a heading element of level 1</li><li>Set the inner text of the heading element to “Hello”</li><li>Place the heading element into the section element</li><li>Create a paragraph element</li><li>Set the inner text of the paragraph element to “My name is Mike”</li><li>Place the paragraph element into the section element</li><li>Place the section element into the document</li><li>Display the document on the screen</li></ol>



<p>As a web developer, the details of how a browser does these things is irrelevant; all that matters is that it does them. This is a perfect example of the difference between these two kinds of programming. In short, <strong>HTML is a declarative </strong><a href="https://en.wikipedia.org/wiki/Abstraction_(computer_science)" rel="noopener"><strong>abstraction</strong></a><strong> wrapped around a web browser’s imperative display engine.</strong> It takes care of the “how” so you only have to worry about the “what.” You can enjoy life writing declarative HTML because the fine people at Mozilla or Google or Apple wrote the imperative code for you when they built your web browser.</p>


<h4 id="javascript-is-an-imperative-language">JavaScript is an imperative language</h4>


<p>We’ve already looked at a simple example of imperative JavaScript in the shopping list example above, and I mentioned how the complexity of an app’s features has ripple effects on the effort required to implement them and the potential for bugs in that implementation. Now let’s look at a slightly more complex feature and see how it can be simplified by using a declarative approach.</p>



<p>Imagine a webpage that contains the following:</p>



<ul><li>A list of labelled checkboxes, each row of which changes to a different color when it is selected</li><li>Text at the bottom like “1 of 4 selected” that should update when the checkboxes change</li><li>A “Select All” button which should be disabled if all checkboxes are already selected</li><li>A “Select None” button which should be disabled if no checkboxes are selected</li></ul>



<p>Here’s an implementation of this in plain HTML, CSS and imperative JavaScript:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper">CodePen Embed Fallback</iframe></div>



<p class="explanation">There isn’t much CSS code here because I’m using the wonderful <a href="https://www.patternfly.org/" rel="noopener">PatternFly design system</a>, which provides most of the CSS for my example. I imported their CSS file in the CodePen settings.</p>


<h4 id="all-the-small-things">All the small things</h4>


<p>In order to implement this feature with imperative JavaScript, we need to give the browser several granular instructions. This is the English-language equivalent to the code in my example above:</p>



<ul><li>In our HTML, we declare the initial structure of the page:<ul><li>There are four row elements, each containing a checkbox. The third box is checked.</li><li>There is some summary text which reads “1 of 4 selected.”</li><li>There is a “Select All” button which is enabled.</li><li>There is a “Select None” button which is disabled.</li></ul></li><li>In our JavaScript, we write instructions for what to change when each of these events occurs:<ul><li>When a checkbox changes from unchecked to checked:<ul><li>Find the row element containing the checkbox and add the <code>.selected</code> CSS class to it.</li><li>Find all the checkbox elements in the list and count how many are checked and how many are not checked.</li><li>Find the summary text element and update it with the checked number and the total number.</li><li>Find the “Select None” button element and enable it if it was disabled.</li><li>If all checkboxes are now checked, find the “Select All” button element and disable it.</li></ul></li><li>When a checkbox changes from checked to unchecked:<ul><li>Find the row element containing the checkbox and remove the <code>.selected</code> class from it.</li><li>Find all the checkbox elements in the list and count how many are checked and not checked.</li><li>Find the summary text element and update it with the checked number and the total number.</li><li>Find the “Select All” button element and enable it if it was disabled.</li><li>If all checkboxes are now unchecked, find the “Select None” button element and disable it.</li></ul></li><li>When the “Select All” button is clicked:<ul><li>Find all the checkbox elements in the list and check them all.</li><li>Find all the row elements in the list and add the <code>.selected</code> class to them.</li><li>Find the summary text element and update it.</li><li>Find the “Select All” button and disable it.</li><li>Find the “Select None” button and enable it.</li></ul></li><li>When the “Select None” button is clicked:<ul><li>Find all the checkbox elements in the list and uncheck them all.</li><li>Find all the row elements in the list and remove the <code>.selected</code> class from them.</li><li>Find the summary text element and update it.</li><li>Find the “Select All” button and enable it.</li><li>Find the “Select None” button and disable it.</li></ul></li></ul></li></ul>



<p>Wow. That’s a lot, right? Well, we better remember to write code for each and every one of those things. <strong>If we forget or screw up any of those instructions, we will end up with a bug</strong> where the totals don’t match the checkboxes, or a button is enabled that doesn’t do anything when you click it, or a row ends up with the wrong color, or something else we didn’t think of and won’t find out about until a user complains.</p>



<p>The big problem here is that there is no <strong><a href="https://en.wikipedia.org/wiki/Single_source_of_truth" rel="noopener">single source of truth</a></strong> for the <a href="https://en.wikipedia.org/wiki/State_(computer_science)" rel="noopener"><strong>state</strong></a> of our app, which in this case is “which checkboxes are checked?” The checkboxes know whether or not they are checked, of course, but, the row styles also have to know, the summary text has to know, and each button has to know. Five copies of this information are stored separately all around the HTML, and when it changes in any of those places the JavaScript developer needs to catch that and write imperative code to keep the others in sync.</p>



<p>This is still only a simple example of one small component of a page. If that sounds like a headache, imagine how complex and fragile an application becomes when you need to write the whole thing this way. For many complex modern web applications, it’s not a scalable solution.</p>


<h3 id="moving-towards-a-single-source-of-truth">Moving towards a single source of truth</h3>


<p>Tools, like React, allow us to use JavaScript in a declarative way. Just as HTML is a declarative abstraction wrapped around the web browser’s display instructions, <strong>React is a declarative abstraction wrapped around JavaScript.</strong></p>



<p>Remember how HTML let us focus on the structure of a page and not the details of how the browser displays that structure? Well, when we use React, we can focus on the structure again by defining it based on data stored in a single place. When that source of truth changes, React will update the structure of the page for us automatically. It will take care of the imperative steps behind the scenes, just like the web browser does for HTML. (Although React is used as an example here, this concept is not unique to React and is used by other frameworks, such as Vue.)</p>



<p>Let’s go back to our list of checkboxes from the example above. In this case, the truth we care about is simple: which checkboxes are checked? The other details on the page (e.g. what the summary says, the color of the rows, whether or not the buttons are enabled) are effects derived from that same truth. So, why should they need to have their own copy of this information? They should just use the single source of truth for reference, and everything on the page should “just know” which checkboxes are checked and conduct themselves accordingly. You might say that the row elements, summary text, and buttons should all be able to automatically <em>react</em> to a checkbox being checked or unchecked. (See what I did there?)</p>


<h4 id="tell-me-what-you-want-what-you-really-really-want">Tell me what you want (what you really, really want)</h4>


<p>In order to implement this page with React, we can replace the list with a few simple declarations of facts:</p>



<ul><li>There is a list of true/false values called <code>checkboxValues</code> that represents which boxes are checked.<ul><li>Example:  <code>checkboxValues = [false, false, true, false]</code></li><li>This list represents the <strong>truth</strong> that we have four checkboxes, and that the third one is checked.</li></ul></li><li>For each value in <code>checkboxValues</code>, there is a row element which:<ul><li>has a CSS class called <code>.selected</code> if the value is true, and</li><li>contains a checkbox, which is checked if the value is true.</li></ul></li><li>There is a summary text element that contains the text “<code>{x}</code> of <code>{y}</code> selected” where <code>{x}</code> is the number of true values in <code>checkboxValues</code> and <code>{y}</code> is the total number of values in <code>checkboxValues</code>.</li><li>There is a “Select All” button that is enabled if there are any false values in <code>checkboxValues</code>.</li><li>There is a “Select None” button that is enabled if there are any true values in <code>checkboxValues</code>.</li><li>When a checkbox is clicked, its corresponding value changes in <code>checkboxValues</code>.</li><li>When the “Select All” button is clicked, it sets all values in <code>checkboxValues</code> to true.</li><li>When the “Select None” button is clicked, it sets all values in <code>checkboxValues</code> to false.</li></ul>



<p>You’ll notice that the last three items are still imperative instructions (“When this happens, do that”), but that’s the only imperative code we need to write. It’s three lines of code, and they all update the single source of truth. The rest of those bullets are declarations (“there is a…”) which are now built right into the definition of the page’s structure. In order to do this, we write our elements in a special JavaScript <a href="https://en.wikipedia.org/wiki/Syntax" rel="noopener">syntax</a> provided by React called JSX, which resembles HTML but can contain JavaScript logic. That gives us the ability to mix logic like “if” and “for each” with the HTML structure, so the structure can be different depending on the contents of <code>checkboxValues</code> at any given time.</p>



<p>Here’s the same shopping list example as above, this time implemented with React:</p>



<div class="wp-block-cp-codepen-gutenberg-embed-block cp_embed_wrapper">CodePen Embed Fallback</iframe></div>



<p>JSX is definitely weird. When I first encountered it, it just felt wrong. My initial reaction was, “What the heck is this? HTML doesn’t belong in JavaScript!” I wasn’t alone. That said, it’s not HTML, but rather <a href="https://reactjs.org/docs/jsx-in-depth.html" rel="noopener">JavaScript dressed up to look like HTML</a>. It is also quite powerful.</p>



<p>Remember that list of 20 imperative instructions above? Now we have three. For the price of defining our HTML inside our JavaScript, the rest of them come for free. <strong>React just does them for us</strong> whenever <code>checkboxValues</code> changes.</p>



<p>With this code, it is now <strong>impossible</strong> for the summary to not match the checkboxes, or for the color of a row to be wrong, or for a button to be enabled when it should be disabled. There is an entire category of bugs which are now impossible for us to have in our app: <strong>sources of truth being out of sync</strong>. Everything flows down from the single source of truth, and we developers can write less code and sleep better at night. Well, JavaScript developers can, at least…</p>


<h3 id="its-a-tradeoff">It’s a trade-off</h3>


<p>As web applications become more complex, maintaining the classic separation of concerns between HTML and JavaScript comes at an increasingly painful cost. HTML was originally designed for static documents, and in order to add more complex interactive functionality to those documents, imperative JavaScript has to keep track of more things and become more confusing and fragile.</p>


<h4 id="the-upside-predictability-reusability-and-composition">The upside: predictability, reusability and composition</h4>


<p>The ability to use a single source of truth is the most important benefit of this pattern, but the trade-off gives us other benefits, too. Defining elements of our page as JavaScript code means that we can turn chunks of it into reusable components, preventing us from copying and pasting the same HTML in multiple places. If we need to change a component, we can make that change in one place and it will update everywhere in our application (or in many applications, if we’re publishing reusable components to other teams).</p>



<p>We can take these simple components and compose them together like LEGO bricks, creating more complex and useful components, without making them too confusing to work with. And if we’re using components built by others, we can easily update them when they release improvements or fix bugs without having to rewrite our code.</p>


<h4 id="the-downside-its-javascript-all-the-way-down">The downside: it’s JavaScript all the way down</h4>


<p>All of those benefits do come at a cost. There are good reasons people value keeping HTML and JavaScript separate, and to get these other benefits, we need to combine them into one. As I mentioned before, moving away from simple HTML files complicates the workflow of someone who didn’t need to worry about JavaScript before. It may mean that someone who previously could make changes to an application on their own must now learn additional complex skills to maintain that autonomy.</p>



<p>There can also be technical downsides. For example, some tools like linters and parsers expect regular HTML, and some third-party imperative JavaScript plugins can become harder to work with. Also, JavaScript isn’t the best-designed language; it’s just what we happen to have in our web browsers. Newer tools and features are making it better, but it still has some pitfalls you need to learn about before you can be productive with it.</p>



<p>Another potential problem is that when the semantic structure of a page is broken up into abstract components, it can become easy for developers to stop thinking about what actual HTML elements are being generated at the end. Specific HTML tags like <code><section></code> and <code><aside></code> have specific semantic meanings that are lost when using generic tags like <code><div></code> and <code><span></code>, even if they look the same visually on a page. This is especially important for accessibility. For example, these choices will impact how screen reader software behaves for visually impaired users. It might not be the most exciting part, but JavaScript developers should always remember that semantic HTML is <a href="https://www.petelambert.com/journal/html-is-the-web/" rel="noopener">the most important part</a> of a web page.</p>


<h3 id="use-it-if-it-helps-you-not-because-its-whats-hot-right-now">Use it if it helps you, not because it’s “what’s hot right now”</h3>


<p>It’s become a trend for developers to reach for frameworks on every single project. Some people are of the mindset that separating HTML and JavaScript is obsolete, but this isn’t true. For a simple static website that doesn’t need much user interaction, it’s not worth the trouble. The more enthusiastic React fans might disagree with me here, but <strong>if all your JavaScript is doing is creating a non-interactive webpage, you shouldn’t be using JavaScript</strong>. JavaScript doesn’t load as fast as regular HTML, so if you’re not getting a significant developer experience or code reliability improvement, it’s doing more harm than good.</p>



<p>You also don’t have to build your entire website in React! Or Vue! Or Whatever! A lot of people don’t know this because all the tutorials out there show how to use React for the whole thing. If you only have one little complex widget on an otherwise simple website, <a href="https://reactjs.org/docs/add-react-to-a-website.html" rel="noopener">you can use React for that one component</a>. You don’t always need to worry about webpack or Redux or Gatsby or any of the other crap people will tell you are “best practices” for your React app.</p>



<p>For a sufficiently complex application, declarative programming is absolutely worth the trouble. It is a game changer that has empowered developers the world over to build amazing, robust and reliable software with confidence and without having to sweat the small stuff. Is React in particular the best possible solution to these problems? No. Will it just be replaced by the next thing? Eventually. But declarative programming is not going anywhere, and the next thing will probably just do it better.</p>


<h3 id="whats-this-ive-heard-about-cssinjs">What’s this I’ve heard about CSS-in-JS?</h3>


<p>I’m not touching that one.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/why-javascript-is-eating-html/">Why JavaScript is Eating HTML</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>Two-Value Display Syntax (and Sometimes Three)</h1>
<p>Chris Coyier — Fri, 08 Nov 2019 21:17:57 +0000</p>
<p>You know the single-value syntax: <code>.thing { display: block; }</code>. The value “block” being a single value. There are <em>lots</em> of single values for <a href="https://css-tricks.com/almanac/properties/d/display/"><code>display</code></a>. For example, <code>inline-flex</code>, which is like <code>flex</code> in that it becomse a flex container, but behaves like an inline-level element rather than a block-level element. Somewhat intuitive, but much better served by a two-value system that can apply that same concept more broadly and just as intuitively.</p>
<p><span id="more-298497"></span></p>
<p>For a deep look, you should read Rachel Andrew’s blog post <a href="https://hacks.mozilla.org/2019/10/the-two-value-syntax-of-the-css-display-property/" rel="noopener">The two-value syntax of the CSS Display property</a>. <a href="https://drafts.csswg.org/css-display/" rel="noopener">The spec</a> is also a decent read, as is this video from Miriam:</p>
<p></p>
<h3>This is how it maps in my brain</h3>
<figure id="post-298501" class="align-none media-298501"><figcaption>Choose <code>block</code> or <code>inline</code>, then choose <code>flow</code>, <code>flow-root</code>, <code>flex</code>, <code>grid</code>, or <code>table</code>. If it’s a <code>list-item</code> that’s a third thing.</figcaption></figure>
<p>You essentially pick one from each column to describe the layout you want. So the existing values we use all the time map out something like this:</p>
<figure id="post-298503" class="align-none media-298503"></figure>
<p>Another way to think about those two columns I have there is <strong>“outside” and “inside”</strong> display values. Outside, as in, how it flows with other elements around it. Inside, as in, how layout happens inside those elements. </p>
<h3>Can you actually use it?</h3>
<p>Not really. Firefox 70 is first out of the gate with it, and there are no other signals for support from Chrome-land or Safari-land that I know about. It’s a great evolution of CSS, but as far as day-to-day usage, it’ll be years out. Something as vital as layout isn’t something you wanna let fail just for this somewhat minor descriptive benefit. Nor is it probably worth the trouble to progressively enhance with <code>@supports</code> and such. </p>
<h3>Tidbits</h3>
<ul>
<li>Check out the <a href="https://drafts.csswg.org/css-display/#transformations" rel="noopener">automatic transformations</a> bit. Just because you set an element to a particular display, doesn’t mean it might not be overruled by a certain situation. I’m assuming it’s mostly talking about an element being forced to be a flex item or grid item.</li>
<li>There is implied shorthand. Like if you <code>inline list-item</code>, that’s really <code>inline flow list-item</code> whereas <code>list-item</code> is <code>block flow list-item</code>. Looks all fairly intuitive.</li>
<li>You still use stuff like <code>table-row</code> and <code>table-header-group</code>. Those are single-value deals, as is <code>contents</code> and <code>none</code>.</li>
<li>Column one technically includes <code>run-in</code> too, but as far as I know, no browser has ever supported <code>run-in</code> display.</li>
<li>Column two technically includes <code>ruby</code>, but I have never understood what that even is.</li>
</ul>
<h3>How we talk about CSS</h3>
<p>I like how Rachel ties this change to a more rational mental and teaching model:</p>
<blockquote>
<p>… They properly explain the interaction of boxes with other boxes, in terms of whether they are block or inline, plus the behavior of the children. For understanding what display is and does, I think they make for a very useful clarification. As a result, I’ve started to teach display using these two values to help explain what is going on when you change formatting contexts.</p>
<p>It is always exciting to see new features being implemented, I hope that other browsers will also implement these two-value versions soon. And then, in the not too distant future we’ll be able to write CSS in the same way as we now explain it, clearly demonstrating the relationship between boxes and the behavior of their children.</p>
</blockquote>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/two-value-display-syntax-and-sometimes-three/">Two-Value Display Syntax (and Sometimes Three)</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>(Why) Some HTML is “optional”</h1>
<p>Robin Rendle — Mon, 16 Sep 2019 16:34:00 +0000</p>
<p>Remy Sharp digs into the history of the web and describes why the <code><p></code> tag doesn’t need to be closed like this:</p>
<pre><code><p>Paragraphs don’t need to be closed
<p>Pretty weird, huh?</code></pre>
<p>Remy writes: </p>
<blockquote>
<p>Pre-DOM, pre-browsers, the world’s first browser was being written by Sir Tim Berners-Lee. There was no reference implementation and certainly no such thing as a parsing specification. The first browser, the WorldWideWeb.app, parsed HTML character by character applying styles as it went along. As opposed to today’s methods whereby a document object model is built up, then rendered.</p>
<p>[…] The paragraph tag (yes, in upper case) was intended to separate paragraphs, not wrap them.</p>
</blockquote>
<pre rel="HTML"><code class="language-markup"><P>
Paragraph one.
<P>
Paragraph two.
<P>
Paragraph three.</code></pre>
<p><span id="more-295912"></span></p>
<p>Weird, huh! Remy wrote this in response to Chris’ post the other day about <a href="https://css-tricks.com/some-html-is-optional/">optional HTML</a> and how browsers will close certain tags for us or even insert the right elements in place.</p>
<p><a href="https://remysharp.com/2019/09/12/why-some-html-is-optional" rel="noopener">To Shared Link</a> — <a href="https://css-tricks.com/why-some-html-is-optional/">Permalink on CSS-Tricks</a></p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/why-some-html-is-optional/">(Why) Some HTML is “optional”</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>Some HTML is “Optional”</h1>
<p>Chris Coyier — Wed, 11 Sep 2019 14:22:10 +0000</p>
<p>There is a variety of HTML that you can just <em>leave out</em> of the source HTML and it’s still valid markup. </p>
<p>Doesn’t this look weird?</p>
<pre rel="HTML"><code class="language-markup"><p>Paragraph one.
<p>Paragraph two.
<p>Paragraph three.</code></pre>
<p>It does to me, but the closing <code></p></code> tags are optional. The browser will detect it needs them and manifest correctly in the DOM anyway. </p>
<p><span id="more-295484"></span></p>
<p>This probably happens to HTML you write and you don’t even know it. For example…</p>
<pre rel="HTML"><code class="language-markup"><table>
  <tr>
    <td></td>
  </tr>
</table></code></pre>
<p>That looks perfectly fine to me, but the browser will inject a <code><tbody></code> in there around that <code><tr></code> for you. Optional in HTML, but the DOM will put it in anyway. </p>
<p>Heck, you don’t really even need a <code><body></code> in the same fashion! Jens Oliver Meiert <a href="https://meiert.com/en/blog/optional-html/" rel="noopener">shares more</a>:</p>
<pre rel="HTML"><code class="language-markup"><link rel=stylesheet href=default.css></code></pre>
<p>Some attributes are “optional” too in the sense that they have defaults you can leave out. For example, a <code><button></code> is automatically <code><button type="submit"></code>.</p>
<p>Jens further <a href="https://meiert.com/en/blog/html-performance/" rel="noopener">argues</a> that these are almost considered <em>optimizations</em>, as it reduces file size and thus network speed. </p>
<p>Me, I don’t like looking at HTML like that. Makes me nervous, since there are actual situations that screw up if you don’t do it right. Not all file names can be left unquoted. Sometimes, leaving off closing tags means enveloping a sibling element in a way you didn’t expect. I’d even sacrifice a tiny smidge of performance for a more resilient site. Sorta like how I know that <code>* {}</code> isn’t a particularly efficient selector, but worrying about CSS selector performance is misplaced worry in most cases (the speed difference is negligible). </p>
<p>I actually quite like <abbr>JSX</abbr> in how strict it forces you to write “HTML.” That strictness helps code formatting (e.g. Prettier) too, as a bonus. </p>
<p>But hey, a perf gain is a perf gain, so I wouldn’t say no to tooling that automatically does this stuff to compiled output. That’s apparently something <a href="https://github.com/kangax/html-minifier" rel="noopener">HTMLminifier</a> can do.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/some-html-is-optional/">Some HTML is “Optional”</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>Clever code</h1>
<p>Robin Rendle — Wed, 17 Apr 2019 14:00:10 +0000</p>
<p>This week, Chris Ferdinandi examined a <a href="https://gomakethings.com/clever-javascript-does-not-mean-simple-or-readable/" rel="noopener">clever JavaScript snippet</a>, one that’s written creatively with new syntax features, but is perhaps less readable and performant. It’s a quick read, but his callout of our industry’s fixation on cleverness is worth… calling out:</p>
<blockquote><p>…we’ve become obsessed as an industry with brevity and clever code, and it results in code that’s sometimes less performant, and typically harder to read and make sense of for most people.</p></blockquote>
<p>He made a similar argument late last month when he wrote about <a href="https://gomakethings.com/readability-is-more-important-than-brevity/" rel="noopener">code readability</a>, noting that brevity might look cool but ultimately leads to all sorts of issues in a codebase: </p>
<blockquote>
<p>Often, web developers are obsessed with brevity. There’s this thing were developers will try to write the same function in the fewest number of characters possible.</p>
<p>Personally, I think brevity is pointless. Readability is a lot more important.</p>
</blockquote>
<p><span id="more-285840"></span></p>
<p>I entirely agree with Chris on this point, however, I think there is one important distinction to make and that’s the difference between code that’s intended as a prototype and code that’s intended for production. As <a href="https://adactio.com/journal/14562" rel="noopener">Jeremy Keith argued</a> a short while ago: </p>
<blockquote><p>What’s interesting is that—when it comes to prototyping—our usual front-end priorities can and should go out the window. The priority now is speed. If that means sacrificing semantics or performance, then so be it. If I’m building a prototype and I find myself thinking “now, what’s the right class name for this component?”, then I know I’m in the wrong mindset. That question might be valid for production code, but it’s a waste of time for prototypes.</p></blockquote>
<p>I agree with Chris that we should be writing code that is easy to read when we’re in production. I also think experimenting with code in this way is a good thing when it comes to prototypes. We shouldn’t ever shy away from playing with code and pushing things a little bit – so long as we’re not doing that in a giant web app with a a team of other developers working alongside us.</p>
<hr />
<p>I’ve noticed that there are some folks that are doing genuinely ingenious things with Sass. I consistently sit back and think, “Wow, I’ve never seen anything like this before.” But when it comes to a production web app that has to be understood by hundreds of people at the same time, I don’t believe that this is the reaction we want when someone looks at the code.</p>
<p>As a result, I’ve been trying to write Sass code that is actually so simple that it almost looks dumb. One easy way to make code a lot simpler is to reduce the amount of nesting:</p>
<pre rel="CSS"><code class="language-css">.element {
  .heading { ... }
}</code></pre>
<p>This looks fine when there’s code inside — and it’s pretty easy to understand — but add a complex bit of design in the mix (say, using pseudo elements and media queries) and you suddenly have a rather complex set of rules in front of you. Creativity and cleverness can be harder to scan and identify one small part of the code that you’re looking for. Plus, in this example, we’ve unnecessarily made our <code>.heading</code> class a little bit more specific which might encourage us to override things in a hacky way elsewhere in the codebase.</p>
<p>We could write the following:</p>
<pre rel="CSS"><code class="language-css">.element { ... }

.element-heading { ... }</code></pre>
<p>I know this looks foolishly simple but the relationship between these two classes is easier to see and easier to extend in the future. Bundling all that code into a single nested class can get out of hand real fast. Even if it happens to look a lot cooler.</p>
<p>(As an aside, Andy Bell’s post on using the ampersand in Sass — and the resulting comments — is a great example of the clash between creativity and practicality.)</p>
<p>Anyway, the point I’m trying to make here is that CSS (and JavaScript for that matter) is a strange language because there are no definite rules you can make about it. It all really depends on the codebase and the project. But I think we can safely say that our code <a href="https://css-tricks.com/simple-boring/">ought to be a lot more boring</a> than our prototypes when it moves to production.</p>
<p>Continue to make prototypes that are wild and experimental or impossibly weird! Code quality be damned.</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/clever-code/">Clever code</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>Resilient, Declarative, Contextual</h1>
<p>Chris Coyier — Mon, 25 Jun 2018 17:34:49 +0000</p>
<p>Keith J. Grant:</p>
<blockquote><p>I want to look at three key characteristics of CSS that set it apart from conventional programming languages: it’s resilient; it’s declarative; and it’s contextual. Understanding these aspects of the language, I think, is key to becoming proficient in CSS.</p></blockquote>
<ol>
<li>Like HTML, unknown or slightly broken CSS doesn’t stop a site in its tracks.</li>
<li>You write something you want to happen in CSS, it happens, and a bunch of related things may happen to. I like Keith’s example with <code>font-size</code>. Increase it, and the container will also grow in height without you having to tell it to.</li>
<li>You can’t understand what CSS is going to do without understanding the DOM structure it is paired with and the other styles at play.</li>
</ol>
<blockquote><p>And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.</p></blockquote>
<p>Easy to learn, a lifetime to master, as they say.</p>
<p><a href="https://keithjgrant.com/posts/2018/06/resilient-declarative-contextual/" rel="noopener">To Shared Link</a> — <a href="https://css-tricks.com/resilient-declarative-contextual/">Permalink on CSS-Tricks</a></p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/resilient-declarative-contextual/">Resilient, Declarative, Contextual</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>Combining the Powers of SEM and BIO for Improving CSS</h1>
<p>Ryan Yu — Mon, 04 Jun 2018 14:07:15 +0000</p>
<p>CSS is easy, some might argue, but that “easiness” can cause messy code. This is especially true through power of preprocessors like Sass or Less where, if you aren’t careful, your CSS can become harder to deal with instead of easier. Sass? Harder? <a href="https://gist.github.com/strann/9900620" rel="noopener">This Gist</a> shows a great example of Sass nesting hell.</p>
<p>If your Sass code looks like that, you can definitely improve your code with <strong>SEM & BIO</strong>, a CSS technique I’ll introduce you to now!</p>
<p><span id="more-271711"></span></p>
<p>In this article, I am going to use the code example below to explain how SEM and BIO works and how they can help enhance your CSS strategy.</p>
<p data-height="470" style="height: 470px; display: flex; align-items: center; justify-content: center; border: 2px solid black; margin: 1rem 0; padding: 1rem; overflow: auto;" data-theme-id="1" data-slug-hash="3666483a5cccb77462210cc623cee2f8" data-default-tab="result" data-user="iamryanyu" data-embed-version="2" data-pen-title="SEM & BIO" class="codepen">See the <a href="https://codepen.io/iamryanyu/pen/3666483a5cccb77462210cc623cee2f8" rel="noopener">Pen</a> by thebabydino (<a href="http://codepen.io/iamryanyu" rel="noopener">@thebabydino</a>) on <a href="http://codepen.io" rel="noopener">CodePen</a>.</p>
<p>Generally, SEM is concerned with high level CSS philosophy whereas BIO is an actual technique to help you write better CSS to achieve SEM. The main purpose of both SEM and BIO is to better handle the <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity" rel="noopener">CSS specificity</a> which is one of the most important concepts you should understand for CSS.</p>
<figure id="post-271712" class="align-none media-271712"><figcaption>Credit: <a href="http://nanajeon.com/" rel="noopener">Nana Jeon</a></figcaption></figure>
<p>First of all, let’s talk about SEM.</p>
<h3>SEM</h3>
<p>SEM stands for:</p>
<ul>
<li>Scalable</li>
<li>Extensible</li>
<li>Maintainable</li>
</ul>
<p>Trying to achieve those three factors can definitely improve your CSS code and it helps you build your components much more solid.</p>
<p>Let’s talk more about each factor in detail.</p>
<h4>Scalable</h4>
<p>A scalable (or reusable) component means that the same looking components should be used wherever you want without making any coding changes.</p>
<figure id="post-271713" class="align-none media-271713"><figcaption>Credit: <a href="http://nanajeon.com/" rel="noopener">Nana Jeon</a></figcaption></figure>
<p>From the CodePen example above, the “Search” button in the header looks exactly same as the ‘Link’ button in the sidebar. When we compare the HTML markup,</p>
<ul>
<li>the “Search” button is <code><button></code> element</li>
<li>but the “Link” button is <code><a role="button" ...></code> element</li>
</ul>
<p>…and even if the markup is different, the styles are identical by using the same classes: <code>.c-btn</code> and <code>.c-btn--yellow</code>.</p>
<p>The button styles are scalable and it allows you to add the same looking components anywhere you want as it won’t be polluted by its parents or siblings. This can save you from the big headache of not knowing why totally unrelated components are broken even if the changes are made on a different component from a totally different place.</p>
<figure id="post-271714" class="align-none media-271714"><figcaption>Source: <a href="https://www.cartoonnetwork.com.au/show/we-bare-bears" rel="noopener">Cartoon Network</a></figcaption></figure>
<h4>Extensible</h4>
<p>An extensible component can easily provide additional features/functionalities without breaking itself or having to be written from scratch.</p>
<p>Let’s look at the CodePen example again.</p>
<p data-height="470" style="height: 470px; display: flex; align-items: center; justify-content: center; border: 2px solid black; margin: 1rem 0; padding: 1rem; overflow: auto;" data-theme-id="1" data-slug-hash="3666483a5cccb77462210cc623cee2f8" data-default-tab="result" data-user="iamryanyu" data-embed-version="2" data-pen-title="SEM & BIO" class="codepen">See the <a href="https://codepen.io/iamryanyu/pen/3666483a5cccb77462210cc623cee2f8" rel="noopener">Pen</a> by iamryanyu (<a href="http://codepen.io/iamryanyu" rel="noopener">@iamryanyu</a>) on <a href="http://codepen.io" rel="noopener">CodePen</a>.</p>
<p>The button in the header and in the main section look quite similar besides the 3D effect. In this case, instead of creating two different sets of buttons having totally different code bases, we could extend the plain button style by just adding the 3D effect to it.</p>
<p>It goes the same with the button in the footer. Even though the button has a different color and size, we could easily extend it by adding or removing new or different features.</p>
<figure id="post-271715" class="align-none media-271715"><figcaption>Credit: <a href="http://nanajeon.com/" rel="noopener">Nana Jeon</a></figcaption></figure>
<h4>Maintainable</h4>
<p>Probably one of the biggest challenges for most front-enders is to understand CSS written by other people, or our past selves. We sometimes spend more time trying to understand the existing code than adding awesomely-written new code.</p>
<p>The issue usually comes from:</p>
<ul>
<li>no comments, whatsoever</li>
<li>over-engineering</li>
<li>no single source of truth</li>
<li>no coding standard/best practice considered</li>
<li>or all of them above</li>
</ul>
<figure id="post-271720" class="align-none media-271720"><figcaption>Credit: <a href="http://nanajeon.com/" rel="noopener">Nana Jeon</a></figcaption></figure>
<p>With SEM and BIO, we can definitely improve the code and save others (including ourselves!) from messy, unmaintainable code.</p>
<h3>BIO</h3>
<p>There are many great techniques out there to improve the way we write CSS, and from my experience, I found the following three techniques that make up the BIO acronym work very well together</p>
<ul>
<li>BEM</li>
<li>ITCSS</li>
<li>OOCSS</li>
</ul>
<figure id="post-271721" class="align-none media-271721"><figcaption>Credit: <a href="http://nanajeon.com/" rel="noopener">Nana Jeon</a></figcaption></figure>
<p>A lot of developers/engineers already know those famous techniques but I would like to go through each of them and talk about the way I use those techniques.</p>
<h4>BEM</h4>
<p><a href="http://getbem.com/introduction/" rel="noopener">BEM</a> is very popular methodology and it has been helping us significantly improve the way we think about CSS and Sass/Less.</p>
<p>BEM stands for:</p>
<ul>
<li>Block</li>
<li>Element</li>
<li>Modifier</li>
</ul>
<figure id="post-271716" class="align-none media-271716"><figcaption>Credit: <a href="http://nanajeon.com/" rel="noopener">Nana Jeon</a></figcaption></figure>
<p>As the bad example above shows, we tend to overuse the power of Sass/Less and falling into nesting-hell. But with BEM, we start to have a very low CSS specificity by maintaining the styles in one (or two) levels of nesting.</p>
<p>If you’ve experienced any battles fighting higher CSS specificity, you will know how painful it is to come out a winner.</p>
<p>Going back to our example, the HTML markup looks like this:</p>
<pre rel="HTML"><code class="language-markup"><div class="o-grid">
  <div class="o-grid__item o-grid__header">
    ...
  </div>
  <div class="o-grid__item o-grid__main">
    ...
  </div>
  <div class="o-grid__item o-grid__sidebar">
    ...
  </div>
  <div class="o-grid__item o-grid__footer">
    ...
  </div>
</div></code></pre>
<p>The example consists of:</p>
<ul>
<li>a block:  <code>.o-grid</code></li>
<li>elements: <code>.o-grid__item</code>, <code>.o-grid__header</code>, <code>.o-grid__main</code>, <code>.o-grid__sidebar</code>, <code>.o-grid__footer</code></li>
</ul>
<p>Because BEM provides a naming convention that stresses unique classes, we don’t have to go into deep nesting like:</p>
<pre rel="SCSS"><code class="language-scss">.o-grid {
  .o-grid__item {
    ...
  }
}</code></pre>
<p>Instead, we can define the styles it with fewer levels:</p>
<pre rel="SCSS"><code class="language-scss">.o-grid__item {
  ...
}</code></pre>
<p>This is the biggest merit of BEM; lowering the CSS specificity which improves the whole CSS coding efficiency and experience.</p>
<p>One issue I still see occasionally even with BEM is poor naming. If you don’t pay enough attention, you can wind up with a really long class name like:</p>
<pre rel="SCSS"><code class="language-scss">/* Yikes! */
.o-grid__item-search-button-text-svg-icon {
  ...
}</code></pre>
<p>When you create a class name, go with the core concept of BEM: your component is a block and all elements inside are individually attached to the block.</p>
<p>From our example again, I named <code>.o-grid__form</code> instead of <code>.o-grid__item-form</code> because the form itself is a separate component and doesn’t have to be tied with and be a child of <code>o-grid__item</code>.</p>
<p>Also, to more efficiently control styles, I have added another class name <code>o-grid__header</code> along with <code>o-grid__item</code> to extend the styles. Moreover, the button contains BEM-styled classes with the approach of OOCSS, which we’ll touch on next.</p>
<h4>OOCSS</h4>
<p>As we have already discussed, there are many great CSS methodologies and strategies helping us improve the way we write CSS. However, I see a lot of folks forcing themselves to decide on one methodology to use out of the bunch.</p>
<p>From my experience, combining methodologies can actually enhance their benefits by combining the best of multiple worlds. For example, I personally have found that BEM and OOCSS work very well together.</p>
<p><a href="http://oocss.org/" rel="noopener">OOCSS</a> stands for <strong>Object Oriented CSS</strong> and you can think of it working like Lego blocks:</p>
<figure id="post-271717" class="align-none media-271717"><figcaption>Source: <a href="https://www.flickr.com/photos/ochre_jelly/32430277156" rel="noopener">Flickr</a></figcaption></figure>
<p>OOCSS creates each individual part separately and then constructs them together in order to build components.</p>
<p>From our example, I have created buttons using the OOCSS naming convention:</p>
<ul>
<li><code>.c-btn</code></li>
<li><code>.c-btn--yellow</code></li>
<li><code>.c-btn--blue</code></li>
<li><code>.c-btn--3d</code></li>
<li><code>.c-btn--large</code></li>
</ul>
<p>To render the yellow search button in our example header, we combine these classes:</p>
<ul>
<li><code>.c-btn</code></li>
<li><code>.c-btn--yellow</code></li>
</ul>
<p>If we want to have the 3D button in the main section, we add in the 3D class, <code>.c-btn--3d</code> and call it a day.</p>
<p>And for the blue button in the footer, we can switch the yellow modifier to blue along with the large modifier. As you can see, the button is not depending on the header block giving us greater flexibility with how we use and repurpose components. And, by doing so, we can construct the buttons without impacting any other components or patterns while gaining the benefit of easily extending new presentational feature, like alternative colors and shapes.</p>
<p>Here example of a button collection created using OOCSS to create the variations: </p>
<p data-height="410" style="height: 410px; display: flex; align-items: center; justify-content: center; border: 2px solid black; margin: 1rem 0; padding: 1rem; overflow: auto;" data-theme-id="1" data-slug-hash="RNjRZz" data-default-tab="result" data-user="iamryanyu" data-embed-version="2" data-pen-title="Modern Button Collection" class="codepen">See the Pen <a href="https://codepen.io/iamryanyu/pen/RNjRZz/" rel="noopener">Modern Button Collection</a> by Ryan Yu (<a href="https://codepen.io/iamryanyu" rel="noopener">@iamryanyu</a>) on <a href="https://codepen.io" rel="noopener">CodePen</a>.</p>
<figure id="post-271718" class="align-none media-271718"></figure>
<p>On top of BEM and OOCSS, with the help of ITCSS, we can further improve our CSS strategy. Let’s look at that method next.</p>
<h4>ITCSS</h4>
<p><a href="https://www.youtube.com/watch?v=hz76JIU_xB0" rel="noopener">ITCSS</a> stands for <strong>Inverted Triangle CSS</strong> and it helps organize CSS by applying a structure that determines how specific to get with a specific component. Lubos Kmetko has written <a href="https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/" rel="noopener">an excellent overview of ITCSS</a> that is worth reading.</p>
<p>You can see how I have put ITCSS to use by splitting styles up by grouped levels of specificity in <a href="https://gist.github.com/iamryanyu/3bf1a3c4d23cbe4e407c1dd95358d9b6" rel="noopener">this Gist</a>.</p>
<p>Based on that example, you can see how I named <strong>components</strong> by adding a namespace to the class. So, for example, a the “button” component is prefixed with a “c” (<code>.c-button</code>) to indicate the component status and prevent it from being mistaken for another item. By doing so, everyone working on the project knows the function of that specific class and how changing its properties might affect other areas.</p>
<p>Here’s a visual that illustrates all the ITCSS levels:</p>
<figure id="post-271719" class="align-none media-271719"></figure>
<p>Let’s go through each section.</p>
<h5>Settings</h5>
<p>Settings are generally a collection of variables that do not generate CSS, but are applied to classes. Some examples include:</p>
<ul>
<li>Base</li>
<li>Color</li>
<li>Typography</li>
<li>Animation</li>
</ul>
<h5>Tools</h5>
<p>Tools also will not produce any CSS yet and are typically preprocessor functions that help write or extend properties on classes:</p>
<ul>
<li>Functions</li>
<li>Placeholders</li>
<li>Mixins</li>
<li>Media queries</li>
</ul>
<h5>Vendors</h5>
<p>Vendors are third-party styles that are being used on a project. Think of things like reset.css, normalize.css, or even Foundation and Bootstrap.</p>
<p>The reason these styles are higher up in the structure is so we can override them if needed. As you may recall, if the same class is called twice, the cascade will render the properties of the second instance, assuming the properties are exactly the same:</p>
<pre rel="SCSS"><code class="language-scss">.btn--large {
  padding: 3em;
}

/* This one wins out */
.btn--large {
  padding: 5em;
}</code></pre>
<p>Just for the side note, in Sass, you can use  <code>~</code> to point to the <code>node_modules</code> folder so you are able to import style assets from the source rather than having to move it into your own directories.</p>
<pre rel="SCSS"><code class="language-scss">@import '~modern-normalize/modern-normalize';</code></pre>
<h5>Objects</h5>
<p>Objects (namespace: <code>o-</code>) are used for design patterns, such as layouts, where items are being arranged rather than decorated. Object classes are used across all pages, so if you make any changes to the object classes, you should be very careful because any changes are going to affect each and every page throughout the website.</p>
<p>The most common object classes I use are:</p>
<ul>
<li><code>.o-page</code>: the most outer container which usually contains <code>max-width: 100vw</code> and <code>overflow: hidden</code>.</li>
<li><code>.o-main</code>: the outer container for the main area.</li>
<li><code>.o-container</code>: the outer container for components and it usually provides a fixed width.</li>
<li><code>.o-content</code>: in case if any extra configuration is needed for the actual content area.</li>
<li><code>.o-grid</code>: if a grid layout with different number of columns are required.</li>
</ul>
<p>Do you use any other object classes? If so, please share with me. 😃</p>
<h5>Elements</h5>
<p>Elements (namespace: <code>e-</code>) are the HTML native elements which we would not style based on the class names. For example, we should provide default styles to <code><a></code> element rather than <code>.link</code> class.</p>
<pre rel="SCSS"><code class="language-scss">// Do this for the default link style
a {
  text-decoration: none;

  &:hover {
    background-color: blue;
    color: white;
  }
}

// Don’t provide the default link style to a class
.link {
  text-decoration: none;

  &:hover {
    background-color: blue;
    color: white;
  }
}</code></pre>
<p>It is because, especially in a CMS like WordPress, you wouldn’t want to add a class every single time you want to use a link in content. Hence, we provide a default style to the <code><a></code> element so without any class, the link will still have good-looking styles.</p>
<h5>Components</h5>
<p>A component (namespace: <code>c-</code>) is a small feature that makes up a part of the website. Think buttons, accordions, sliders, modal dialogs, etc. Each component is fully functional by itself and does not rely on any other components. This fact should be considered when you name the component.</p>
<p>For example, the button in the main section from the example above shouldn’t be called <code>.c-main-button</code> because main scopes it inside the <code>main</code> section and limits the use of it in other places, like a sidebar. Something like <code>.c-btn</code> is much nicer because the button is no longer tied to any other specific sections of the page.</p>
<p>If you need any extra features, you can always extend properties with a BEM modifier (combining powers!) or use <strong>Scope</strong>, which is coming up in a bit.</p>
<h5>Patterns</h5>
<p>A lot of developers/engineers use the terms <em>component</em> and <em>pattern</em> synonymously and that’s totally fine if you are more comfortable with that. It is just my preference to separate those two terms.</p>
<p>For a general rule of thumb, I think of a pattern (namespace: <code>p-</code>) as a combination of components but in a way that is <strong>not</strong> scaleable.</p>
<p>For example, I would consider the accordion as a component. It is scaleable and reusable on its own, meaning that it can be used in other parts of the website without making any changes even if the accordion would contain other components such as buttons. </p>
<p>On the other hand, the header, for example, would be a pattern because it is <strong>not</strong> scaleable (the header cannot be used in the content or sidebar area) and also contains other components such as buttons, accordions, menus, logos, search form etc.</p>
<h5>Scope</h5>
<p>Be warned; I <em>only</em> use the scope if it’s absolutely necessary. The purpose of the scope (namespace: <code>s-</code>) is to give us the highest specificity so we can overwrite any styles for a specific purpose.</p>
<p>Remember, If you find yourself using the <em>scope class</em> many times, you might be writing styles that are <em>too</em> specific and you should consider refactor your CSS structure.</p>
<p>Here is a simple example of the use of the scope class, <code>.s-home</code>.</p>
<pre rel="SCSS"><code class="language-scss">.c-accordion {
  .s-home & {
    // Changing the background color specically on the homepage
    background-color: tomato;
  }
}</code></pre>
<p>As a side note, the above example could actually be refactored by providing a modifier to the accordion (e.g., <code>.c-accordion--bg-tomato</code>) instead of using the scope class. That would be a much more extensible way of writing and make the component more modular.</p>
<h5>Utility</h5>
<p>Sometimes you may want to make changes only for a certain style in a specific place. In that case, utility (namespace: <code>u-</code>) classes can help us update it without changing the whole CSS structure.	 	 </p>
<p>For example, the font-size of the accordion heading is set to 32px.	 	 </p>
<pre rel="SCSS"><code class="language-scss">.c-accordion__heading {	 	 
  font-size: rem(32);	 	 
}</code></pre>
<p>But if the font size is only different in the news section of your site and does not change anywhere else, then you might want to apply the utility class instead of setting higher specificity with the parent class or scope class.</p>
<pre rel="HTML"><code class="language-html"><button aria-expanded="false" class="c-accordion__heading u-font-size--24" aria-controls="sect1" id="accordion1id" type="button">...</button></code></pre>
<pre rel="SCSS"><code class="language-scss">.u-font-size--24 {	 	 
  font-size: rem(24) !important;	 	 
}</code></pre>
<p class="explanation">Please note that we all know <code>!important</code> is BAD but I added <code>!important</code> to the value. It is because when we use the utility class, we are absolutely sure we want the specific style to be updated as we want. Also the utility class should overwrite any other styles, so having the <code>!important</code> actually works well here for the utility classes. That said, the utility classes should only play a role as a helper. It should never be used for structuring your CSS.</p>
<p>Like scope classes, if you are using too many utility classes, you should check with designer if the design can be more consistent across the site.</p>
<h5>Extra Namespace</h5>
<p>On top of the namespaces we discussed above, there are two more I often use:</p>
<ul>
<li><code>is-</code>: this indicates the state of the block or element. Most commonly used class is <code>.is-active</code>, like the active link in navigation.</li>
<li><code>js-</code>: this indicates that the specific element is bound to JavaScript events. For example, <code>js-menu-click</code> indicates that the element is bound to the click event.</li>
</ul>
<h4>Linting</h4>
<p>Finally making rules with <code>.stylelint</code> and <code>.eslint</code> can significantly improve the code quality.</p>
<p>In the frontend workflow, I don’t make it as a recommendation; I make it mandatory so that failing of the rules won’t get approved.</p>
<p>In this way, we can ensure that the coding quality stays at its best and provide better code to other developers, including your future self.</p>
<h3>In Action</h3>
<p>In this section, I’d like to discuss how we could use SEM and BIO. I have made a simple, practical example to get us started:</p>
<p data-height="470" style="height: 470px; display: flex; align-items: center; justify-content: center; border: 2px solid black; margin: 1rem 0; padding: 1rem; overflow: auto;" data-theme-id="1" data-slug-hash="fea46688b060099de1af29b8c9c1319e" data-default-tab="result" data-user="iamryanyu" data-embed-version="2" data-pen-title="SEM & BIO" class="codepen">See the <a href="https://codepen.io/iamryanyu/pen/fea46688b060099de1af29b8c9c1319e" rel="noopener">Pen</a> by iamryanyu (<a href="http://codepen.io/iamryanyu" rel="noopener">@iamryanyu</a>) on <a href="http://codepen.io" rel="noopener">CodePen</a>.</p>
<p>The main practice with the example is to build an accordion that can be used as:</p>
<ul>
<li>a normal accordion but with different color themes in the main section</li>
<li>a menu in the sidebar</li>
<li>a block displaying social media icons in the footer</li>
</ul>
<p>What we’re achieving is a component that is:</p>
<ul>
<li><strong>Scalable</strong>: as it can be added in any part of the page without any coding changes</li>
<li><strong>Extensible</strong>: as it can serve different functionalities with the core functions unchanged</li>
<li><strong>Maintainable</strong>: as it is organized in a way that makes sense</li>
</ul>
<p>To achieve SEM, BIO has been used including:</p>
<ul>
<li><strong>BEM:</strong> <code>.c-accordion</code> as a block and its children as elements, also used modifiers, e.g., <code>.c-accordion--light</code> and <code>.c-accordion--dark</code></li>
<li><strong>ITCSS:</strong> The ordering/sorting of SASS files handles the CSS specificity quite well. For example, the accordion button in the sidebar contains <code>class="c-accordion__trigger p-sidebar-menu__button"</code> which the pattern (<code>p-</code>) overwrites the component (<code>c-</code>) with no issues.</li>
<li><strong>OOCSS:</strong> the accordion is constructed with several classes, for example, <code>class="c-accordion c-accordion--dark c-accordion--single"</code> which creates a dark theme with opening a single panel only each time.</li>
</ul>
<h3>Final thoughts</h3>
<p>I have used this approach for almost all of my projects including universities, government departments, commercial retailers, and many other websites. In each case, I have successfully delivered all of the projects to the clients (almost no issues during the client approval stage and delivered on time); this approach has worked for me very well so far and I think it could for you as well.</p>
<p>That being said, technologies always change (especially on the front end) and I am more than happy to hear and discuss any of your ideas/approaches/strategies that worked for you. Let me know in the comments!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/combining-the-powers-of-sem-and-bio-for-improving-css/">Combining the Powers of SEM and BIO for Improving CSS</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>CSS Basics: The Syntax That Matters & The Syntax That Doesn’t</h1>
<p>Chris Coyier — Mon, 12 Feb 2018 14:28:08 +0000</p>
<p>When you’re starting to play around with CSS at the <em>very beginning</em>, like any other language, you have to get used to the syntax. Like any syntax, there are a bunch of little things you need to know. Some characters and the placement of them is <em>very</em> important and required for the CSS to work correctly. And some characters are more about clean looking code and generally followed standards but don’t matter for the CSS to work.</p>
<p><span id="more-265703"></span></p>
<p>First, so we have the terminology down:</p>
<figure id="post-254416" class="align-none media-254416"><figcaption>A CSS ruleset consists of a selector and delcaration(s) wrapped in curly braces.</figcaption></figure>
<h3>Important: Braces</h3>
<p>All CSS rulesets must have opening and closing curly braces:</p>
<p><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 600"><title>braces</title><rect width="1000" height="600" fill="#333"/><rect x="567" y="74" width="374" height="175" fill="#8c0a0a"/><rect x="56" y="458" width="374" height="98.8" fill="#8c0a0a"/><rect x="567" y="359.2" width="374" height="197.61" fill="#8c0a0a"/><circle cx="250.75" cy="119.75" r="28.75" fill="#59c414"/><circle cx="99.75" cy="202.75" r="28.75" fill="#59c414"/><text transform="translate(89.61 130.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header {<tspan x="0" y="40.8" xml:space="preserve">  padding: 20px;</tspan><tspan x="0" y="81.6">}</tspan></text><text transform="translate(602.59 130.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header <tspan x="0" y="40.8" xml:space="preserve">  padding: 20px;</tspan><tspan x="0" y="81.6">}</tspan></text><text transform="translate(89.61 405.09)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header {<tspan x="0" y="40.8" xml:space="preserve">  padding: 20px;</tspan><tspan x="0" y="81.6">}</tspan></text><text transform="translate(602.59 405.09)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header <tspan x="0" y="40.8" xml:space="preserve">  padding: 20px;</tspan></text><circle cx="769" cy="119.75" r="28.75" fill="#f90b0b"/><circle cx="99.75" cy="475.75" r="28.75" fill="#f90b0b"/><circle cx="769" cy="394.75" r="28.75" fill="#f90b0b"/><circle cx="615.34" cy="478.75" r="28.75" fill="#f90b0b"/></svg></p>
<p>If you miss the opening brace, CSS will keep reading as if the next bit of text is still part of the selector. Then it’s likely to find a character like <code>;</code> which are invalid as part of a selector and break. Breaking likely means it will screw up itself and the next ruleset, and <a href="https://codepen.io/chriscoyier/pen/KZjQEP" rel="noopener">recover after that</a>.</p>
<p>Missing a closing brace is a bit worse in that it’s likely to mess up the rest of the entire CSS file unless it somehow finds a double closing brace and can resolve that first missing one. </p>
<p>Overall point: <strong>braces are very important!</strong></p>
<p class="explanation">Preprocessing languages like Sass and Less offer a syntax feature called <a href="http://sass-lang.com/guide#topic-3" rel="noopener">nesting</a>. This can be convenient, but note that when these preprocessors run and produce CSS, that nesting is removed because CSS by itself doesn’t support that. If you copy nested CSS into regular CSS, you’ll have problems with the braces.</p>
<h3>Sometimes Important: Spaces</h3>
<p>There are just a few places that spaces are important in CSS. One of the most important is in selectors. <strong>One</strong> space in a selector means you’re selecting descendants of the previous part of the selector. The selector <code>body p</code> means “select p elements that are descendants of the body element”. That space means a lot. Hopefully it’s clearly different than <code>bodyp</code> which won’t select anything (there is no <code><bodyp></code> element). But it’s not different from <code style="white-space: pre;">body    p</code>. Multiple spaces mean the same as one space. </p>
<p><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 600"><title>spaces</title><rect width="1000" height="600" fill="#333"/><text transform="translate(135.61 130.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">body ul li</text><text transform="translate(135.61 184.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">bodyulli</text><text transform="translate(135.61 287)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header .title</text><text transform="translate(135.61 454)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header .title</text><text transform="translate(135.61 341)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace"><tspan xml:space="preserve">.header       .title</tspan></text><text transform="translate(135.61 495)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header.title</text><text transform="translate(67 162.5)" font-size="70.5" fill="#f20000" font-family="MyriadPro-Regular, Myriad Pro">≠</text><text transform="translate(67 491.5)" font-size="70.5" fill="#f20000" font-family="MyriadPro-Regular, Myriad Pro">≠</text><text transform="translate(67 325.5)" font-size="70.5" fill="lime" font-family="MyriadPro-Regular, Myriad Pro">=</text></svg></p>
<p>You can’t put spaces in properties, function names, or anywhere you name things. Adding spaces in those situations effectively changes the names, breaking them.</p>
<p><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 1028.13"><title>spaces-3</title><rect width="1000" height="1028.13" fill="#333"/><circle cx="351.15" cy="135.49" r="39.61" fill="#f90b0b"/><circle cx="390.76" cy="421.98" r="39.61" fill="#f90b0b"/><circle cx="311.55" cy="587.33" r="39.61" fill="#f90b0b"/><circle cx="614.03" cy="811.32" r="39.61" fill="#f90b0b"/><circle cx="500" cy="421.98" r="39.61" fill="#f90b0b"/><circle cx="580.22" cy="421.98" r="39.61" fill="#f90b0b"/><circle cx="540.61" cy="188.49" r="39.61" fill="#f90b0b"/><text transform="translate(135.61 90.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">background-image: url(tiger.jpg);</text><text transform="translate(135.61 144.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">background – image: url(tiger.jpg);</text><text transform="translate(135.61 198.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">background-image: url (tiger.jpg);</text><text></text><text></text><text transform="translate(135.61 319)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">@keyframes goRoundAndRound { }<tspan x="0" y="56">@keyframes go-round-and-round { }</tspan><tspan x="0" y="112">@keyframes go round and round { }</tspan></text><text transform="translate(135.61 541)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">:root {<tspan x="0" y="56" xml:space="preserve">  –theme main: red;</tspan><tspan x="0" y="112" xml:space="preserve">  –theme-second: red;</tspan><tspan x="0" y="168">}</tspan><tspan x="0" y="224">body {</tspan><tspan x="0" y="280" xml:space="preserve">  background: var(–theme main);</tspan><tspan x="0" y="336" xml:space="preserve">  background: var(–theme-second);</tspan><tspan x="0" y="392">}</tspan></text><circle cx="101.03" cy="80.85" r="22.03" fill="#59c414"/><polyline points="93.41 78.95 89.61 82.71 97.21 90.36 112.46 75.11 108.66 71.35 97.25 82.54 93.41 78.95" fill="#fff"/><circle cx="101.03" cy="309.03" r="22.03" fill="#59c414"/><polyline points="93.41 307.13 89.61 310.89 97.21 318.54 112.46 303.29 108.66 299.53 97.25 310.72 93.41 307.13" fill="#fff"/><circle cx="137.1" cy="641.75" r="22.03" fill="#59c414"/><polyline points="129.48 639.85 125.67 643.61 133.28 651.26 148.53 636.01 144.73 632.25 133.32 643.44 129.48 639.85" fill="#fff"/><circle cx="137.1" cy="865.24" r="22.03" fill="#59c414"/><polyline points="129.48 863.34 125.67 867.1 133.28 874.75 148.53 859.5 144.73 855.74 133.32 866.93 129.48 863.34" fill="#fff"/></svg></p>
<p>Other than that, spacing doesn’t matter much in CSS.</p>
<p><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 600"><title>spaces_1</title><rect width="1000" height="600" fill="#333"/><text transform="translate(100.61 130.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header {<tspan x="0" y="40.8" xml:space="preserve">  padding: 20px;</tspan><tspan x="0" y="81.6">}</tspan></text><text transform="translate(614.59 130.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace"><tspan xml:space="preserve">.header       {</tspan><tspan x="0" y="40.8" xml:space="preserve">  padding:20px;</tspan><tspan x="0" y="81.6" xml:space="preserve">              }</tspan></text><text transform="translate(614.59 279.09)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace"><tspan xml:space="preserve">  .header {</tspan><tspan x="0" y="40.8" xml:space="preserve">padding:   20px;</tspan><tspan x="0" y="81.6" xml:space="preserve">          }</tspan></text><text transform="translate(614.59 454)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header{<tspan x="0" y="40.8" xml:space="preserve">padding:   20px;  }</tspan></text><text transform="translate(94.61 287)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header{<tspan x="0" y="40.8" xml:space="preserve">  padding: 20px;}</tspan></text><text transform="translate(100.61 433.99)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header{padding:20px;}</text><circle cx="56" cy="155.85" r="28.75" fill="#59c414"/><polyline points="46.05 153.37 41.09 158.27 51.01 168.25 70.91 148.35 65.95 143.45 51.07 158.06 46.05 153.37" fill="#fff"/><circle cx="56" cy="300" r="28.75" fill="#59c414"/><polyline points="46.05 297.52 41.09 302.42 51.01 312.4 70.91 292.5 65.95 287.6 51.07 302.2 46.05 297.52" fill="#fff"/><circle cx="56" cy="425.25" r="28.75" fill="#59c414"/><polyline points="46.05 422.77 41.09 427.67 51.01 437.65 70.91 417.75 65.95 412.85 51.07 427.45 46.05 422.77" fill="#fff"/><circle cx="578.84" cy="155.85" r="28.75" fill="#59c414"/><polyline points="568.89 153.37 563.93 158.27 573.85 168.25 593.74 148.35 588.78 143.45 573.9 158.06 568.89 153.37" fill="#fff"/><circle cx="578.84" cy="300" r="28.75" fill="#59c414"/><polyline points="568.89 297.52 563.93 302.42 573.85 312.4 593.74 292.5 588.78 287.6 573.9 302.2 568.89 297.52" fill="#fff"/><circle cx="578.84" cy="462.74" r="28.75" fill="#59c414"/><polyline points="568.89 460.26 563.93 465.17 573.85 475.14 593.74 455.25 588.78 450.34 573.9 464.95 568.89 460.26" fill="#fff"/></svg></p>
<p>I’d encourage you to be consistent with your spacing, and produce clean and readable CSS. You might want to reference some <a href="https://css-tricks.com/css-style-guides/">CSS style guides</a> out there for some formatting best practices. </p>
<p class="explanation">Even the <code>!important</code> rule in CSS, which comes after a the value in a delcaration like <code>body { background: white !important; }</code> doesn’t have any spacing requirements. It could have any amount of space before it, or none.</p>
<p>The removing of space in CSS is actually a best practice for performance, so you might notice that when peeking at the raw CSS of websites in production. </p>
<figure id="post-265992" class="align-none media-265992"></figure>
<p>You’re better off leaving that minification of CSS to a tool that processes your CSS for you, leaving the original alone. We’ll have to cover the options for that in other post.</p>
<h3>Mostly Important: Semicolons</h3>
<p>Each declaration in a ruleset (a property and value pair) ends in a semicolon. That semicolon is required, otherwise CSS will keep reading the next property as if it’s part of the value of the previous declaration. </p>
<p><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 600"><title>semicolons</title><rect width="1000" height="600" fill="#333"/><circle cx="458.29" cy="494.95" r="28.75" fill="#59c414"/><circle cx="458.29" cy="148.5" r="28.75" fill="#f90b0b"/><text transform="translate(89.61 340.59)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header {<tspan x="0" y="40.8" xml:space="preserve">  padding:     20px;</tspan><tspan x="0" y="81.6" xml:space="preserve">  max-width:  600px;</tspan><tspan x="0" y="122.4" xml:space="preserve">  background: black;</tspan><tspan x="0" y="163.2" xml:space="preserve">  color:      white</tspan><tspan x="0" y="204">}</tspan></text><text transform="translate(89.61 74)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header {<tspan x="0" y="40.8" xml:space="preserve">  padding:     20px;</tspan><tspan x="0" y="81.6" xml:space="preserve">  max-width:  600px</tspan><tspan x="0" y="122.4" xml:space="preserve">  background: black;</tspan><tspan x="0" y="163.2" xml:space="preserve">  color:      white;</tspan><tspan x="0" y="204">}</tspan></text></svg></p>
<p>You can leave off the semicolon on the last declaration in a ruleset. I’d warn that doing so manually will cause more trouble than it’s worth, and best left to minification tools.</p>
<h3>Important: Avoiding Stray Characters</h3>
<p>This is important in <em>any</em> language. Every character in code matters, so random other characters will almost certainly break things.</p>
<p><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 600"><title>extra-chars</title><rect width="1000" height="600" fill="#333"/><text transform="translate(141.61 130.6)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header {<tspan x="0" y="40.8" xml:space="preserve">  padding: 20px;</tspan><tspan x="0" y="81.6">}</tspan></text><circle cx="359.14" cy="394.75" r="28.75" fill="#f90b0b"/><circle cx="811.24" cy="433.84" r="28.75" fill="#f90b0b"/><circle cx="625.34" cy="148.5" r="28.75" fill="#f90b0b"/><text transform="translate(141.61 405.09)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace"><tspan xml:space="preserve">.header {  {</tspan><tspan x="0" y="40.8" xml:space="preserve">  padding: 20px;</tspan><tspan x="0" y="81.6">}</tspan></text><text transform="translate(596.59 405.09)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header {<tspan x="0" y="40.8" xml:space="preserve">  padding: ~20px;</tspan><tspan x="0" y="81.6">}</tspan></text><text transform="translate(578.59 119.75)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header {<tspan x="0" y="40.8" xml:space="preserve">  /padding: 20px;</tspan><tspan x="0" y="81.6">}</tspan></text><circle cx="102.86" cy="150.5" r="28.75" fill="#59c414"/><polyline points="92.91 148.02 87.95 152.92 97.87 162.9 117.77 143 112.81 138.1 97.93 152.7 92.91 148.02" fill="#fff"/></svg></p>
<h3>Not Important: Line Breaks</h3>
<p>A line break is treated like any other white space in CSS, so feel free to use them as needed, as long as it doesn’t break any other spacing rule like we talked about above.</p>
<p><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1000 928.56"><title>line-breaks</title><rect width="1000" height="928.56" fill="#333"/><text transform="translate(173.61 340.59)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.bar <tspan x="0" y="40.8">{</tspan><tspan x="0" y="81.6" xml:space="preserve">  background-image:</tspan><tspan x="0" y="122.4" xml:space="preserve">    url(texture.png),</tspan><tspan x="0" y="163.2" xml:space="preserve">    url(tiger.jpg);     }</tspan></text><text transform="translate(173.61 639.07)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.button::after <tspan x="0" y="81.6">{</tspan><tspan x="0" y="122.4" xml:space="preserve">     content:</tspan><tspan x="0" y="163.2" xml:space="preserve">         ">";</tspan><tspan x="0" y="204">} </tspan></text><text transform="translate(173.61 74)" font-size="30" fill="#fff" font-family="'Operator Mono SSm A', 'Operator Mono SSm B', 'Source Code Pro', Menlo, Consolas, Monaco, monospace">.header {<tspan x="0" y="40.8" xml:space="preserve">  box-shadow:</tspan><tspan x="0" y="81.6" xml:space="preserve">     0    0   5px      rgba(0, 0, 0, 0.5),</tspan><tspan x="0" y="122.4" xml:space="preserve">     20px 2px 5px -5px rgba(0, 0, 0, 0.5);</tspan><tspan x="0" y="163.2">}</tspan></text><circle cx="93.05" cy="148.5" r="28.75" fill="#59c414"/><polyline points="83.1 146.02 78.14 150.92 88.06 160.9 107.95 141 102.99 136.1 88.11 150.7 83.1 146.02" fill="#fff"/><circle cx="107.95" cy="437.45" r="28.75" fill="#59c414"/><polyline points="98.01 434.97 93.05 439.87 102.97 449.85 122.86 429.95 117.9 425.05 103.02 439.65 98.01 434.97" fill="#fff"/><circle cx="107.95" cy="742.57" r="28.75" fill="#59c414"/><polyline points="98.01 740.09 93.05 744.99 102.97 754.97 122.86 735.07 117.9 730.16 103.02 744.77 98.01 740.09" fill="#fff"/></svg></p>
<hr>
<p>All in all, CSS syntax isn’t so hard. Good luck!</p>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/css-basics-syntax-matters-syntax-doesnt/">CSS Basics: The Syntax That Matters & The Syntax That Doesn’t</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
<article>
<h1>CSS Ruleset Terminology</h1>
<p>Chris Coyier — Wed, 03 May 2017 12:06:22 +0000</p>
<p>I was trying to think of the name of a thing in the CSS vernacular the other day. It made me think we should have some kind of reference right here on CSS-Tricks, as a site with CSS in the title probably ought to have! So, here’s the basics.</p>
<p><span id="more-254414"></span></p>
<figure id="post-254416" class="align-none media-254416"></figure>
<p>Breaking that down…</p>
<ul>
<li>The <em>whole thing</em> is a <strong>ruleset</strong>.</li>
<li>The curly braces and everything inside is a <strong>declaration block</strong>.</li>
<li>The bit before the opening curly brace is a <strong>selector</strong>.</li>
<li>Each key/value pair, as separated by a colon and ending in a semicolon, is a <strong>declaration</strong>.</li>
<li>In those key/value pairs, the key is a <strong>property</strong> (or <em>property name</em>), and the value is a <strong>value</strong> (or <em>property value</em>).</li>
</ul>
<p>Marco Biedermann once created this diagram out of HTML and CSS itself, which I think is exceedingly clever:</p>
<p data-height="549" style="height: 549px; display: flex; align-items: center; justify-content: center; border: 2px solid black; margin: 1rem 0; padding: 1rem; overflow: auto;" data-theme-id="1" data-slug-hash="osurh" data-default-tab="result" data-user="marcobiedermann" data-embed-version="2" data-pen-title="CSS Terminology" class="codepen">See the Pen <a href="https://codepen.io/marcobiedermann/pen/osurh/" rel="noopener">CSS Terminology</a> by Marco Biedermann (<a href="http://codepen.io/marcobiedermann" rel="noopener">@marcobiedermann</a>) on <a href="http://codepen.io" rel="noopener">CodePen</a>.</p>
<h3>More</h3>
<ul>
<li>Louis Lazaris: <a href="https://www.impressivewebs.com/css-terms-definitions/" rel="noopener">CSS Terms and Definitions</a></li>
<li>Divya Manian: <a href="http://nimbupani.com/css-vocabulary.html" rel="noopener">CSS Vocabulary</a></li>
<li>MDN: <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Syntax" rel="noopener">Syntax</a></li>
</ul>
<hr />
<p><small><a rel="nofollow" href="https://css-tricks.com/css-ruleset-terminology/">CSS Ruleset Terminology</a> originally published on <a rel="nofollow" href="https://css-tricks.com">CSS-Tricks</a>, which is part of the <a href="https://try.digitalocean.com/css-tricks/?utm_medium=rss&utm_source=css-tricks.com&utm_campaign=family_&utm_content=">DigitalOcean</a> family. You should <a href="https://css-tricks.com/newsletters/">get the newsletter</a>.</p>

</article>
</main></body></html>