DEV Community: Matthew Dean

CSS: the language with no syntax

Matthew Dean — Fri, 08 Aug 2025 18:13:43 +0000

Congratulations! You have fallen prey to my clever click-bait-y title, but before you dismiss this topic out-of-hand ("Because," you say, "of course CSS has syntax"), or leave a smarmy comment, allow me to walk you through what CSS is, and how it's defined.

Some context: I've been a maintainer of Less.js (the CSS pre-processor) for about 10 years, and the lead maintainer for most of that time. When I started contributing, I knew very little about not just CSS parsing, but about parsing in general.

In the last 5 years, I've worked on not just Less but other CSS-related parsing projects, including one that re-imagines both Less and Sass parsing for the modern era (which has yet to be released). I've used a variety of parsing approaches, parsing generators, and parsing libraries.

In some cases, I had to abandon the use of certain parsers or parsing approaches because they just weren't flexible for CSS, and the reason is that CSS has no single syntax.

What do I mean by "single syntax"?

You can think of CSS as kind of a collection of "micro-syntaxes". CSS has kind of a top-level syntax for how things are organized (okay, okay, yes you can say that at the top level, there is a syntax), and then the way it works is that individual specifications have their own micro-syntax that defines the syntax within that location. On the whole, each micro-syntax has generally tried to mostly look consistent with other micro-syntaxes before it, but that doesn't mean that they actually are consistent or that the same syntax has the same semantics, as you might find in other languages.

You might be scratching your head at this, because, if you've never had to parse it, or have that parser actually understand all its component pieces (as it does in a system like Less), CSS syntax looks the same everywhere.

So, let's illustrate this with some examples.

Assignment or selector?

What does the colon : mean in CSS? You might be tempted to say assignment, because of this:

.box {
  /* Look! There's an assignment `:` operator! */
  color: red;
}

Okay, then, what does this mean?

/* Look! There's... oh... */
div:hover {}

"Not a problem!" you say. This is at the start of a ruleset (also called a qualified rule), and we know that pseudo-classes and pseudo-elements start with : followed by an identifier. Easy peasy.

Alright, so a pseudo-selector looks like :ident, cool. Okay, how do we parse this?

.box {
  /* Look There's a pseudo-... oh... */
  color:red;
}

Okay, never mind that, we say. We can just have two modes! When we're at the "top-level" where we're expecting rulesets, we can have : mean one thing, and then inside it, we can have it mean another.

Welp, not so fast. One of the reasons Less and Sass were so popular for so long was the convenience of nesting rulesets and at-rules inside each other, and both engines support this:

.box {
  button:hover {}
}

CSS Nesting has now been adopted by the core CSS language itself, and as of 2024, is now supported in browsers. So this form is valid in CSS now too.

If you know anything about parsing, you may now start to recognize that we're looking at an example of "infinite lookahead" and backtracking. Some engines either don't support infinite lookahead, or don't support it without major performance penalties. The reason it's "infinite" is because of cases like:

.box {
  foo:red blue green yellow purple brown black grey...

As we parse this, we have to ask:

is this a property called "foo" with a value of red blue green yellow purple brown black grey etc? or
is this a selector selecting an element called "foo" with a pseudo-class of :red and descendant elements of blue green yellow purple brown black grey etc?

There are ways to avoid infinite lookahead, of course, such as having a list of all known CSS properties, and/or having a list of all known valid HTML elements, but this is already a little too deep into parsing, so let's get back on track to syntax and how CSS is defined.

How CSS syntax is actually defined

The way that CSS syntax is defined is that you can think of it as having a basic outer structure with "slots" where syntax definitions can go.

These "slots" are:

An at-rule's "prelude" (everything before outer ; or its {} block)
An at-rule's block ({}) contents
A property's value
A pseudo-selector's () block, if it exists
A CSS function's () block

Example 1: at-rules

Instead of having general parsing rules, parsing is specified by the at-rule specification itself. For example: the @supports at-rule parses (or can parse) property/value pairs, like:

@supports (transform-origin: 5% 5%) {
}

...whereas the @scope rule expects to be parsing selectors e.g.

@scope (.card) {}

Example 2: :nth-child() and dimensions

In general, CSS considers units like -1 to be distinct tokens. If you have this, for example, this will be parsed as two values: 1 and -1:

/* This has a value of 1 -1 */
padding: 1-1;

However, :nth- functions define their own micro-syntax: An+B. Instead of the argument to :nth-child(n-1) being interpreted as two tokens, n and -1, it's interpreted as "n minus 1", which, confusingly, is different from the calc() function because, again, calc() has its own micro-syntax!

CSS: What's a "list"?

One of the most frustrating and inconsistent parts of CSS syntax is that it has no formal definition for "lists". Or, rather, it has a collection of syntaxes which all can represent lists, but not all of them are consistent in describing what's in the list and what isn't.

That said, probably the most consistent right now in CSS syntax and micro-syntaxes is comma-separated and semi-colon-separated lists, which is generally defined like:

// List members are ['1', '2', '3']
1, 2, 3

// List members are ['1 1', '2 2', '3 3']
1 1, 2 2, 3 3

// List members are ['a: 1', 'b: 2', 'c: 3']
a: 1; b: 2; c: 3;

That is, in general:

Each comma splits the value into distinct members of the list i.e. if you have two commas, you have 3 members of the list.
A semi-colon-separated list "groups" other values that, themselves, can have comma-separated lists.

You may be scratching your head and saying, "What do you mean, 'in general'? Isn't this always true in CSS?"

Sorry, but nope. Where this concept begins to fall apart is in CSS function calls. The reason it begins to fall apart is because of these ambiguities in CSS syntax:

CSS functions can receive arguments. Those arguments are CSS values.
CSS function arguments are a comma-separated list, BUT (importantly),
CSS values can also be a comma-separated list.

With early CSS functions, this wasn't an issue. All functions received values that didn't themselves have commas. Eventually, though, use cases and CSS proposals emerged for functions that could receive commas. And not just functions. There emerged use cases where other CSS values, which could be comma-separated, might themselves need sub-lists as individual parts of the value.

So, now what were proposal authors to do? If your guess is, "Hopefully, something consistent?" then prepare to be horribly disappointed.

The Many Failed Attempts at Lists-of-Lists Syntax in CSS

1. The `/` separator

You'll probably recognize this. In some CSS values, the list separator is a slash (/) character. But it would be a mistake to consider it a list separator like , or ;. I'll explain.

Let's take border-radius as an example:

border-radius: 10px 20px / 30px 40px;

In the border-radius syntax, this syntax is used to figure out "radius pairs" for corners. I don't want to get into the minutia of the border-radius syntax, but suffice to say that the / separates a set of values preceding it from a set of values following it. In this case, it's a list like: ['10px 20px', '30px 40px'].

You might be tempted, then, to think of the / as just another list separator. But, of course, that isn't the case.

When calc() was introduced, it recognized that almost all programming languages use / as a "division operator". It wasn't going to re-invent the wheel, so the calc() micro-syntax uses it for division and not as a list separator:

/** This means "20px divided by 2" and not
 * "a list containing '20px' and '2' */
calc(20px / 2);

Some property sets, like background-* for example, use comma-separated lists for individual properties, and slash-separated lists for other properties. So, when they get put together, you may get a value like this:

background: url(a.png) left top / cover, url(b.png) right / contain;

From a syntax perspective, what does this value mean? If you're familiar with the background property(s), you may instinctively be able to read this unambiguously. But let's look at this from purely a syntax perspective.

Can you tell me what the "lists" or "lists of lists" are from these CSS values?

unknown: one two / three four;
unknown: one / two three, four;
unknown: one, two three / four;

If your brain says, "The comma splits the value into list pairs, and the slash further splits THOSE values into list pairs," it's a good guess, but, in CSS, that's just not true. It's entirely dependent on the micro-syntax of the given property. You have to know the property name to know how to understand the syntax that follows.

In the case of background, this is how these lists are actually grouped semantically:

background: url(a.png) left top / cover, url(b.png) right / contain;

/**
  background: [
    [
      'url(a.png)',
      'left top'
      'cover'
    ],
    [
      'url(b.png)',
      'right',
      'contain'
    ]
  ]
*/

If the / divided lists consistently across CSS, then the semantic division of this value would be:

background: [
    [
      'url(a.png) left top',
      'cover'
    ],
    [
      'url(b.png) right',
      'contain'
    ]
  ]

Even url(a.png) left top requires you to understand the micro-syntax of background to know that url(a.png) is the background-image and left top represents a single property background-position and not two distinct properties. ✨ Micro-syntaxes! ✨

2. Lists of lists in function (or "function-like") calls

One of the first functions that needed a list of lists was var(). You might think of it as having two values, and it does: the custom property name and the fallback value:

color: var(--theme-color, red);

However, CSS authors had to resolve something: what about values that have commas? The solution, in this case? Just treat everything after the first comma as being absorbed into a single value.

font-family: var(--theme-font, 'Helvetica', sans-serif);

Is the comma consistent here? Again, take the var() out of this and just think of CSS functions as a general syntax. What does this mean?

unknown: new-css-function(one, two, three);

Is that a function that is taking 3 value arguments? Or is it taking one comma-separated value argument?

Well, in the case of var(), delightfully, it's neither. It's taking 2 arguments, the second of which can be a comma-separated argument.

From a language syntax perspective, that's kind of insane, but it gets better!

A note about Less / Sass's handling of lists of lists

Since both Less and Sass (the SCSS variant) are supersets of CSS, there are cases where each had to solve lists-of-lists from a wholistic syntax perspective since CSS offers no consistent guidance in this regard.
Sass let's you wrap values in parentheses to pass lists to functions and mixins:
value: sass-function((1, 2, 3), 4, 5);
Less prefers that you be more explicit, because parentheses may be part of a valid value (think media query syntax), so it asks you to use Less's escape ~ character to more clearly denote that you want the final value to be without the parentheses:
value: less-function(~(1, 2, 3), 4, 5);

3. The CSS Functions and Mixins Module

Probably the most bizarre and perverse twist on trying to come up with a solution for lists of lists is the new CSS functions and mixins module proposal.

It uses NONE of the prior solutions, including Sass / Less prior art, to define lists of lists and comes up with yet another. So, if you're counting, CSS and CSS preprocessor syntax now have:

comma-separated lists
semi-colon separated lists
slash-separated lists (inconsistent)
parentheses-grouped lists (Less and Sass)
...a brand new one defined by this module: curly-brace-grouped lists

This syntax ends up looking like this:

 width: --max-plus-x({ 1px, 7px, 2px }, 3px);

Let me be clear: it's not that I think this syntax is bad, necessarily; it's just that it's Yet Another Micro-syntax. IMO it has these two flaws:

Flaw 1

Until now, curly braces in CSS has actually been a mostly-consistent syntax, denoting a group of rules, like:

/* We thought we understood curly braces in CSS... */
.box {
  color: red;
  background: black;
}

The authors of this module proposal have decided to break that syntax convention, entirely, such that one of the few syntax "rules" will now be, again, removed from "reliable" syntax. (Not that CSS ever specified that curly braces should / would always contain rules; it's just been a consistent syntax convention until now.)

Flaw 2

Instead of CSS authors saying, "You know what? Maybe we should make a formal 'list of lists' standard in CSS and start using it," the use of this format for this module has no general applicability, and there are no plans to migrate it anywhere else.

In other words, if CSS were a single syntax, a syntax proposal with this would come with certain expectations to update other syntaxes for function calls or values to be able to use it, such as:

/* Supporting this moving forward: */
font-family: var(--theme-font, { 'Helvetica', sans-serif });
/* Instead of the inconsistent `rgb(100 100 100 / 0.5)` syntax */
color: rgb({ 100, 100, 100 }, 0.5);

There's no such proposal here. It's just Yet Another Micro-syntax.

CSS - not one syntax, but a smorgasbord of micro-syntaxes

Listen: I love CSS! Sure, from a language syntax perspective, it resembles something like Howl's Moving Castle. But, from a beginner perspective, its relatively-lean syntax means that it's easy to write and quite forgiving. In some ways, its weaknesses are also its strengths.

Just... don't ever try to build a CSS parser. Become a tomato farmer instead.

Addendum: despite knowing better, I've currently building a new CSS parsing & processing framework anyway, to replace Less / Sass / CSS modules / Tailwind / Styled Components / other styling systems, so follow me on here and/or leave a comment if you want to hear about it!

Why, after 20 years as a JavaScript developer, I switched to semicolons

Matthew Dean — Sun, 13 Jul 2025 20:07:46 +0000

This is a first of a series I thought I'd start writing (and hopefully continue writing) about my experiences over 36 years as a programmer, and 20+ years as a professional web developer. (Am I old now? I think I'm old.)

First, what are we talking about? If you're new to JavaScript, you may know that JavaScript is rather forgiving of statement terminations. JavaScript isn't alone in this. Go, Swift, Kotlin, Ruby, Python, Lua... they all make semicolons optional at the end of statements.

In JavaScript, the spec calls this Automatic Semicolon Insertion or ASI. The simplified explanation is that if JS sees what would be a syntax error, and it thinks a semicolon might fix it, it inserts one automatically.

Here's an example:

let one = 1
let two = 2

Early in the culture of JavaScript development, almost all code examples you would find online, though, always had semicolon terminators, like:

let one = 1;
let two = 2;

The semicolon-less era

In the early 2010s, this started to shift. Web development, as a culture, was getting more and more sophisticated, which led to more subject-matter experts with in-depth knowledge, including of esoteric concepts like ASI.

Many JavaScript developers began to say, "Look, semicolons are optional 99% of the time. Why not just omit them, as a standard?" For many, because semicolons seemed unnecessary, then they were just a form of visual noise.

Around the same time, teams were promoting coding with the same style, for easier maintenance and for making fewer decisions. So this new "standard" began to be incorporated in linting tools so that semicolon terminators were now not just optional, they were actually forbidden in a given codebase.

Anyway, this is a lot of probably unnecessary history, which many readers may already know. The point is, why did I, after adopting semicolon-less JavaScript for over ten years, decide to abandon this as of this year (2025)?

99% is not 100%

JavaScript doesn't require semicolons most of the time, but when it does, errors can suddenly become very unintuitive. Let's take this code example (demonstrating variable swapping via array destructuring), which I borrowed from this Medium post:

let varOne = 'Hello'
let varTwo = 'World'

[varOne, varTwo] = [varTwo, varOne]

JavaScript will actually parse that second statement as:

let varTwo = 'World'[varOne, varTwo] = [varTwo, varOne]

If I paste the above code example in VSCode, and let TypeScript try to explain the error to me, I don't get something like "semicolon missing between line two..." blah blah blah, instead I get these errors:

'varTwo' implicitly has type 'any' because it does not have a type annotation and is referenced directly or indirectly in its own initializer
Type 'any[]' is not assignable to type 'string'
Index signature in type 'String' only permits reading.
Left side of comma operator is unused and has no side effects.

Sure, if you know ASI rules, after a bit of head-scratching, you may eventually realize a semicolon is necessary here. The reason is that JavaScript will not insert a semicolon before ( or [ at the start of a line,

You can, of course, just add in one of two ways: either the end of the second statement or the start of the third, like:

// Option 1
let varOne = 'Hello'
let varTwo = 'World';

[varOne, varTwo] = [varTwo, varOne]

// Option 2
let varOne = 'Hello'
let varTwo = 'World'

;[varOne, varTwo] = [varTwo, varOne]

Interestingly most "Ditch your Semicolon" advocates have recommended Option 2, because you're not altering the second statement in order to resolve the third.

Code can start to look weird fast

Despite many advocates insisting that the above example was rare, as I said, it can make errors unintuitive, but, also, if you're working in a team where someone needs to review your code and isn't as familiar with ASI quirks, the above solutions can easily look like a typo.

Additionally, in the 2010s, destructuring patterns, including re-assignment via destructuring, were not as prevalent, as it only began to be supported in middle of 2016.

For these reasons, over time, I found myself needing to pepper in semicolons, because:

I began to use destructuring more in my own code, including re-assignment via destructuring.
I began to use TypeScript almost exclusively.

TypeScript: adding additional problems for ASI

Why would TypeScript make this issue worse? Let's take the following code, in JS:

let input = document.querySelector('input.url')
input.focus()

This works fine! But let's take this into TypeScript:

let input = document.querySelector('input.url')
input.focus()
// - errors: 'input' is possibly null
//           Property 'focus' does not exist on type 'Element'

Okay, let's fix that by casting this to what we know this element actually is.

let input = document.querySelector('input.url')
(input as HTMLInputElement).focus()

All of the sudden, both these lines are reporting errors, even though we only changed the second line. Why? Because TypeScript imports all the same ASI quirks as JavaScript, meaning a line that starts with ( continues the statement.

This began to increasingly happen to me. I would fix a type problem, which would then require me to wrap something in parentheses, which then would create new errors, which then I'd grumble and insert an awkward-looking semicolon there at the start of the statement.

What was the issue with semicolons in the first place?

Eventually, I began to wonder what I was really gaining by leaning on ASI. As software developers, we're used to looking at semicolons at the end of statements. In fact, if you're a web developer, you're used to putting them at the end of CSS declarations. They just aren't a big deal.

And as to visual noise? Because they are so ubiquitous, they start to visually disappear anyway.

They don't even arguably require more typing. I have both ESLint and "Fix on save" enabled in VSCode, meaning every save will just quietly fix any missing semicolons.

As a result, I've discovered that I actually think about semicolons less by using them than by not using them. There's just less cognitive overhead. Statements end with semicolons, full stop. Same-line statements are separated with semicolons. (Almost) all statements have semicolon companions. I no longer have to think about semicolons while destructuring or fixing type problems. My code is no longer confusing my C# colleagues who may be reviewing it.

Moving forward;

Anyway, for me, while this is arguably not the largest issue or problem to have, I thought it would be an interesting dive into code style decisions. And I would imagine some of the same logic may apply to other code that uses optional semicolons, and I'd be interested to hear about that!

Photo by Sudharshan TK on Unsplash

Simplicity as a Feature

Matthew Dean — Fri, 26 Nov 2021 23:55:06 +0000

I recently came across the article "Complexity is killing software developers," and I've been thinking about it ever since.

The article covers a broad spectrum around software development in general, but I've been thinking specifically around the domain of front-end web development, and the multiple layers of abstraction we often buy into as being zero-cost--essentially: all feature benefits, with no significant drawbacks.

We write our components in JavaScript. Except it isn't. It's TypeScript. We write a function call to update the DOM. Except it isn't a function call. It's JSX (TSX). It'll be a function call later. The JSX contains markup of what HTML elements it will render. Except it doesn't. They're "styled components", all of which are abstracted from both the elements they render and the CSS that will eventually be read by a browser. We include this component in our HTML document, except we don't. Someone wrote a 200-line Webpack config file that will magically split this component and others, along with other assets and resources, and render a linked document, based on an abstracted template. Maybe Webpack itself is abstracted, behind a tool like Next.js or Vite.

At my company, I started working on a site and just mentally tallying the layers of abstraction: styled components, TypeScript, React, Redux, route strings as typed enums, content as JSON...and I started to wonder: was all this necessary? Is it worth it?

Or another way to ask it: what is this costing us?

First of all, I have to acknowledge that this question is ironic coming from someone who's been one of the maintainers of Less (the CSS pre-processor) for the last few years. So, it should be said that I'm not against any of these abstractions on their face. I may have strong opinions about this or that tool, but there's no question (to me) that the rise of reactive libraries were a net benefit to web development, or the adoption of component-based design. I've often advocated strongly for tools like TypeScript.

That said, in the past little while, I've started to feel differently, and I've been thinking about this problem from a different perspective. What I've started to see is that, where we used to add these tools to solve a particular pain point where we had before, as a culture, we in web development have acclimated to complexity regardless of the costs. Why wouldn't we use Webpack? We used it before. Why wouldn't we use TypeScript? It's what we're comfortable with.

I think what we've failed to recognize--and I will include myself in this--is that for each benefit it may provide, there is a maintenance and cognitive overhead cost (among other costs) in each additional abstraction that we add into our workflow.

Our monorepo takes forever to run yarn install, and no one knows exactly why. The complex nest of dependencies is not something we've been able to really dig into yet, as we're plowing through each sprint. Each app takes mountains of time to compile, and to run tests, and bundles seem unnecessarily large, but to decipher that just takes more time with each layer of abstraction.

Recently, I switched our dev build compiler of some of our shared packages to SWC from TypeScript (along with removing other abstractions), which, on the one hand, is great! You definitely should explore doing that.

But... on the other hand, I was solving a problem that we ourselves had created, and this sacrilegious thought also occurred to me: what if we weren't compiling / transpiling our code at all? How much faster would that be?

Immediately after I had that thought, I looked around me to make sure the web development gods were not about to smite me. After all, we've lived in a world of, if not TypeScript, surely at least Babel-ified JavaScript, but there's a question if that's needed anymore.

I'm not the first one to have this thought. Rich Harris, a prominent figure in web development, having developed Ractive, Rollup, and Svelte, had this to say about moving from TypeScript back to JavaScript (with JSDoc type annotations): "Among other things, the resulting code is generally smaller than transpiled code. Building, testing etc all become much less finicky. And .d.ts files are still generated from source code."

I don't want to make this entirely about TypeScript; for many teams, TypeScript may be the best option! But I think there's an overlooked value in sincerely asking the question of just how complex any project needs to be, and recognizing that each layer of abstraction is not zero-cost. It may increase development time, even as it decreases it in other areas. It may increase build time or deploy time. It may increase tech debt. It can increase cognitive overhead, or the time to onboard a new developer.

Do you need React, or will Svelte do? Or maybe something even lighter?

Do you need Less / Sass, or styled components, or is your design system simple enough that regular ol' CSS will work?

Do you need Webpack? Or is there something simpler, maybe with fewer options, but with less cognitive overhead?

Do you need Redux, or can you use Zustand? Do you even need a global state library?

Do you need JSX? Do you need TypeScript?

I've begun to think about this as Simplicity as a Feature. Just in the way that we may optimize for performance, and build for Performance as a Feature, I'm starting to think we should optimize our tools and codebases for simplicity. Not to use the simplest tools but to simply use only the tools with only the features that we really need. And if we start to need that next abstraction, that's okay! Sometimes there are things that are trade-offs for performance, just like there are things that are trade-offs for simplicity.

But the leaner you keep your tools and your code, in theory, the faster you and your team can iterate, build, and deploy.

So stop using giant boilerplate-y project templates with every conceivable feature and tool you might ever need. If you use TypeScript, it's okay to not use it on some things! Heck, it's okay to manually write an .html file! It doesn't make you a bad developer, I promise!

And if you're new to web development, don't buy into web sites and apps needing to be necessarily complex, and you needing to learn and use myriad layers of abstraction.

It's okay for things to be simple. That might even be best.