Frontend Dogma

5 Questions for Miriam Suzanne

by and ( on , tagged , , , (toot this?)

Miriam Suzanne is a co-founder of OddBird, an agency that builds custom web tools and applications for clients, teaches development workshops, and contributes back to the community with open-source tools. Jens was happy to speak with her.

Jens: What are you working on these days?

Miriam: I’ve been teaching in-depth CSS workshops for developers and teams. Too often, we teach and learn CSS as a series of unrelated properties, when the reality is a much more integrated system of layout modes and intertwined features. Properties can take their meaning from context—the values of other properties! If you are used to imperative programming, or functional methodology, this can seem like a confusing mess. But with the right mental model, it’s a powerful way to express design intent across unknown devices, interfaces, and languages.

That teaching (along with contributions through Open Collective) helps to fund my time on the CSS Working Group, as an Invited Expert. We meet regularly to discuss issues related to CSS, and develop new features for the language. I’m working on a number of issues related to container queries (which shipped in browsers recently) and scope (which has started to ship), helping with discussions around masonry layout and anchored positioning, and beginning to develop CSS-native mixins and functions.

Jens: What has you excited about CSS?

Miriam: It’s wonderful to see people “get” CSS, and start to see how it works. I like the way this language encourages experimentation—people often want to try something new, and see what happens!

I think some of the new features that we’ve been working on at the CSSWG also help to clarify aspects of the system that may have been unclear. For example, Cascade Layers call attention to other aspects of the cascade like style origins and importance. The more we teach those hidden CSS features to developers, the easier it is to understand how and why CSS works the way that it does.

Another example is the two-value display syntax. It doesn’t add a lot of new functionality to the language, or provide any dramatic shortcuts—instead it helps to clarify the syntax we already have. The display property has two functions: setting both inner and outer display types. In general, we only set one (e.g., setting the inner display value to grid) and allow the other to be set implicitly (outer display will be set to block). Alternately, we often set the outer display to block or inline, with an implicit inner-display of flow. The relation between those inner and outer values is more clear when we understand the two-value syntax:

.example {
  /* these pairs have the same meaning */
  display: block;
  display: block flow;

  display: grid;
  display: block grid;

  /* legacy values can be updated */
  display: inline-flex;
  display: inline flex;

  display: inline-block;
  display: inline flow-root;

Jens: What trend in frontend development are you most concerned about?

Miriam: I have a long-running concern about the industry writing people (especially disabled people) off as “edge cases” who may not be “worth the cost or effort” to support. The entire design of the Web is constructed around making content accessible to everyone, on any device. “Web for all, Web on everything” is the motto of the W3C. If we approach these tools as they are intended, we can make highly accessible sites the default!

Recently I see that playing out as a hyper focus on “developer experience,” which leads us towards more and more complicated frameworks and build steps. Many of these tools stand between the developer and the web platform in ways that end up making our work harder in the long run, and also result in less accessible sites. It doesn’t have to be this complicated!

Jens: For someone new to frontend development, how could they go about it?

Miriam: Start by understanding the mental models of HTML and CSS. These are the materials of all web development. It doesn’t matter if you hand-build custom furniture, or work with large-scale manufacturing—both require a knowledge of the materials involved. JavaScript is also an essential part of the web platform, but it is used as a tool for manipulating HTML, so learn HTML first.

Different people learn in different ways. I was mostly self-taught, but also took several classes and workshops along the way. For me, it was especially helpful to build sites for myself—I learned new skills as I tried to solve new problems. Building myself a blog, and then a site for my theater, and various side projects. Having a goal of what to make can help focus you on what you need to learn to get there.

If you know the basics of HTML, CSS, and JS—you can quickly pick up the details of any particular tooling or frameworks required for a job. Did you learn Tailwind, but you’re applying for a company that uses Sass? Don’t worry, they’re both tools for writing CSS. If you understand the material, you’ll be fine.

Jens: If frontend developers could make one adjustment to their ways of working or learning, what would it be?

Miriam: Learn CSS Grid! I hear again and again that Flexbox is “good enough” so why bother learning grid. But I disagree: Flexbox isn’t “good enough,” flexbox is fantastic! But it’s not the right solution to every layout. Flexbox and grid were designed to work together, solving different problems. There are some exceptions, but generally: If you need to set the flex-basis to any fixed length or percentage, you’d probably have an easier time using grids. Grids are one of the best CSS features out there, and it’s sad that so many people have avoided learning how they work. We’re making layout harder than it needs to be.

If you’re interested in learning more, I have several upcoming workshops. Check out for the latest details.

Jens: Thank you…!