If I draw a banner shaped box in the browser with CSS, what do you see? Do you see a banner that is exactly 48 pixels tall and 608 pixels wide and wonder wtf is up with those ugly numbers? Or do you see a responsive element built from the content out?

<div class="banner">
  idgaf how tall or wide I am… throw anything at me and I will happily adapt \o/
</div>

.banner {
  font-size: 1rem;
  padding: 1rem 2rem;
  max-width: 38rem;
}

What makes this ☝️ a sturdy, maintainable, flexible banner that browsers, screen readers, developers working on it in the future, content authors — and users — will love?

• Type scale takes the lead on sizing and spacing. We don’t cram text into a rigid box. Nope, we do something way cooler; we craft a flexible box to always adapt to any content. ✌️
• Height is not declared. We let the browser do a calculation based on font‑size, line‑height and padding. With our example banner, it’s height would often end up at 48px but it depends — and that is exactly how we want it. Users can increase the size of the text in their browser, developers can modify related elements later, or the text can become a whole lot longer, but none of these changes will cause our banner to break. 💪
• Width is responsive to the viewport. But we set a maximum width to ensure readability, because long lines are hard to read. Our 38rem is not a magic number, and it’s not arbitrarily chosen. Together with the horizontal padding, this creates a maximum line length (called measure in typographic terms) of a recommended ~80 characters. 👌

Is this design or is it development?

For me — and the way my brain works — it’s quite obviously both. Separating this type of work into silos, different processes or skill sets is artificial and makes absolutely no sense to me.

Translating from design to code

The designers that I collaborate with learn how to code. 💅 But I’m imagining what happens on cross functional teams where frontend developers work with non-coding designers, and how (best case scenario) something like this happens:

• Design work happens, and a static sketch contains a banner at exactly 600 x 50 pixels.
• But the designer and the developer have a good working relationship, they both know how browsers work, and share an understanding that sketches shouldn’t be taken literally.
• They have built a design system together, so even though this piece of user interface is new, there are known patterns of design details to follow.
• …and yay, the developer will translate this sketch into code and the responsive, flexible banner it should be. Content out, with spacing and measure. Like our banner example.

This is not bad. But is it… the best process? Even if we are translating sketches of excellent UI design to top‑notch frontend code; it is still translation. The act of translating is not the same activity as an author writing in their native language.

Designing with code

Thinking past this simplified banner example, the potential for diversion increases a shitload. Design decisions informed by code are different from those made without. Maybe they tend to be more boring?! Sure. And it’s worth stating that there can be plenty of reasons for choosing translation as a process. Sometimes this is exactly what you want, like when Murakami is translated to English so I can read his books. I understand how this can be needed on large teams building complex systems.

But maybe… boring is what you want, and what your design system needs. I am convinced that design decisions informed by code have the potential for being more web fluent, more pragmatic and will be based on an honest use of the materials we use to build the web.