[Robin]: My favorite website at the moment is Volume, “a publishing platform for high-quality illustrated books.” It’s a place where you can kickstart book-related projects but what gets made at the end are these enormous and beautiful bits of graphic design.
Just take a look at how relatively simple the layout is:
As you scroll through each project there are these big pull quotes and although I don’t often like them, I think they work extremely well here because of how gosh darn pretty they are:
With nothing more than a splash of color, some big type, and a few well-placed images, the Volume website becomes so much more interesting than it might otherwise be. The nifty thing about this is that these are tools we all have out our fingertips.
Speaking of typography, I also stumbled upon this piece for the New York Times by Jason Farago all about art and power. As you scroll through the piece the painting will zoom in so that Jason can describe that part in more detail:
Splitting Time Between Product and Engineering Efforts
Sarah Drasner wrote this great post about the difficulties of managing product improvements (like shipping new features) and setting aside enough time to work on engineering projects (such as large refactors and the like). Sarah writes:
At each company I’ve worked, we have had a split between time spent on Product initiatives and Engineering work. The percentages always changed, sometimes 70% Product, 30% Engineering, sometimes as much as a 50/50 split. The impetus is to make sure that Engineering spends a portion of their time building new features, but also ensures we can do “our own” work such as address technical debt, upgrade systems, and document our code.
The trouble is, it’s one thing to say this at the outset, and another to make it a reality. There are some reasons that I’ve seen this model fail, not because people don’t understand in theory that it’s valuable, but because in practice, there are some common pitfalls that you have to think through.
This is a great reminder that communication is key when it comes to making websites. And it reminds me of something Chris mentioned the other day when it comes to what strengths are most important for a developer. He describes how he needs “communication skills out of myself and the developers, even more so than your ability to write code directly. […] So, if you can’t [communicate], it makes you a worse developer.”
What are ways we can communicate better though?
Well, I really like Kelly Sutton’s idea of writing a weekly update: he found that if you’re starting any large engineering project then sometimes weekly updates like a blog can be sent to the whole company. Kelly writes:
The weekly update is a long-running document or series of internal blog posts that captures a team’s impact for the current week.
When there is no impact to talk about, we might discuss some of our activity or output. When discussing activity or output, lessons learned or progress can be a good thing to include.
If enough weeks pass where we either have nothing to write about or there is no impact, we need to take a hard look in the mirror. What are we working on, and why is it not incrementally delivering value or helping us learn?
CSS Is, In Fact, Awesome
In a comment on my favorite blog post about CSS, Steve Frank (co-founder of Panic) once wrote about how he came up with the infamous CSS IS AWESOME design:
It was 2009 and I’d spent what seemed like hours trying to do something in CSS that I already knew I could do in seconds with tables. I was trying really hard to do it with CSS because that’s what you’re supposed to do, but I just wasn’t very good at it (spoiler alert: I’m still not very good at it).
I do have a slightly better grasp on the concept of overflow now, but at the time it just blew my mind that someone thought the default behavior should be to just have the text honk right out of the box, instead of just making the box bigger like my nice, sensible tables had always done.
Anyway, I just had this moment of pure frustration and, instead of solving the problem properly, I spent 5 minutes creating a snarky mug and went back to using tables. Because that’s my signature move in times of crisis.
Jim Nielsen wrote about all this recently when he argued that — despite all the jokes about CSS being a bad language — CSS is in fact awesome:
CSS doesn’t guess at what you’re trying to do.
Want to let the containing box grow dynamically with its contents? You can do that with a little more CSS. Want to maintain sizing and cut off content when it overflows its containing box? You can do that with a little different CSS. […] CSS doesn’t know which of those—or others—were your intention. Rather than guess, it starts at a base level and branches into a variety of outcomes with each additional styling rule.
This is the power of CSS. It gives you options. Use them or don’t.
Every time I’ve bumped into something like that when it comes to CSS — ”why doesn’t this work!” — I’ve always discovered that there’s an extremely good reason why this peculiar thing works the way it does. It’s not so much that CSS is confusing; it’s more that I’ve assumed CSS works one way without me thinking about all the other possibilities and edge cases.
The Ping Attribute
Here’s something I’d never heard of before: the ping attribute for anchor elements. Stefan Judis wrote about how we might use this attribute, like so:
<a href="https://www.stefanjudis.com/popular-posts/"
ping="https://www.stefanjudis.com/tracking/">
Read popular posts
</a>What’s this all about? Well, it lets you track when a link is clicked. Once you click that anchor element above, the browser would send a POST request with a bunch of information about that click. Weird, huh?
Chris then followed this up with some thoughts of his own:
There are heaps of downsides though. You don’t exactly get a nice API for sending along metadata. The best you could do is append a query string for extra data (e.g., was the link in the footer? or was it in a blog post?). But perhaps the biggest limitation is that it’s only for anchor links. If you were building a really serious event tracking thing, you’d want it to be useful for any type of event (not just clicks) on any type of element (not just links). So it’s not terribly surprising this is almost entirely the JavaScript’s domain.
I’d be interested to see how folks are using this attribute today. (Google does.)
Comparing the New Generation of Build Tools
This is an incredibly in-depth post from Hugh Haworth where he compares the next generation of build tools such as esbuild, Snowpack, Vite, and wmr. Hugh writes:
Whether we’re writing a small side project or a big production site, all these tools speed up feedback loops and increase productivity. They’ve opened up the gates to ask what’s necessary in the JavaScript ecosystem and whether we can start losing the cruft brought by legacy modules and browsers. These tools are going to lower the barrier-to-entry for new developers by providing a leaner, faster developer environment with fewer abstractions between the code that gets written and the code that runs in the browser.
If you’re getting sick of waiting for your dependencies to download and your build steps to run, I’d recommend giving this new generation of tooling a try.
On this note, SvelteKit is now in public beta. It’s like Next for Svelte, but a framework for building apps quickly with Svelte. I’ve never used it before but I keep hearing super interesting things about it. Anyway, Rich Harris wrote about what it was like to use Snowpack for the first time whilst working on SvelteKit:
Snowpack created an entirely new category of dev tooling. Rather than bundling your app in development, as we’ve been doing with webpack and Rollup for the last several years, Snowpack is an unbundled dev server that uses the browser’s native import and does 1:1 transformations of things like Svelte components on the fly. As a result you get quick startup, simple caching and instant hot module reloading. Once you experience this way of working, it will ruin you for anything else.
This sounds very exciting.
Gaps? Gasp!
Eric Meyer writes in to say that we can start using gap on flexbox elements to space things apart:
With gap, you can gap your grids, your flexboxes, and even your multiple columns. It’s gaptastic!
So now you can position flex items like this:
.element {
display: flex;
gap: 1em;
}One thing I noticed a while back was how a lot of folks tend to pick Grid over Flexbox simply because of how handy gap is. With Flexbox you’d always have to do something bonkers with negative margins in order to space things correctly. But no longer! Safari will soon support this and then all major browsers will have good coverage.
Sponsor
Fauna
The serverless Jamstack database with built-in GraphQL. Fauna is a flexible, developer-friendly, database delivered to you as a secure, cloud API with native support for GraphQL.
Sponsor
Ten Years of Jetpack!
That’s a huge milestone, yes, but what’s more impressive is everything Jetpack has accomplished in that time:
- 122 billion blocked malicious login attempts. 9,330,623 of those on CSS-Tricks.
- 269 million site backups. Last backup of CSS-Tricks: 3 minutes ago, as we write.
- 24 trillion images served by Jetpack CDN. Incredibly, this a free feature of Jetpack.
- 61.6 billion site searches. Try the site search on CSS-Tricks!
- 50 billion related posts displayed. Related posts plugins are heavy on the server, but not with Jetpack!
- 1.6 trillion tracked page views.Those are the numbers at workwith WordPress being some 40% of the web.
- 2.6 billion shared social posts. The @css Twitter account runs itself thanks to Jetpack.
Jetpack has gone from neat idea to playing an integral in the WordPress ecosystem in the past ten years. Give it a try and, for a limited time, get 40% off your first year on all Jetpack plans.
[Chris]: CSS is really moving these days. I pontificated in a private chat the other day, aside from the early days of CSS’ creation…
Might be the most productive period in CSS history?
… to the general agreement of that sentiment. Container queries! Scroll timelines! New color functions! Logical properties! Aspect ratio! That and so much more. Don’t worry, we’ll have articles on everything we don’t already.
But also some trepidation: with this kind of velocity comes accidents. Sometimes there is value in slow movement. “Slow, like brisket.” as Dave Rupert says. We’ll see. I’m pretty stoked to see so much innovation at the core language level.
There’s innovation elsewhere as well. At the JavaScript level, for example. This is my surprised face: 😐. I kid, I kid. I just saw 🧁 vanilla-extract, a new CSS-in-JS player with a very excellent name:
Basically, it’s “CSS Modules-in-TypeScript” but with scoped CSS Variables + heaps more.
I would think it would support a vanilla CSS syntax with a name like that, but alas. I’m a big fan of the build-time CSS generation and the scoping.
There is innovation at the CSS authoring level as well, tools-or-not. For example, Mike Aparicio recently wrote about his COOL CSS methodology:
Component Styles
Individual components are styled to be used in any context and composed into larger components using utility styles.Utility Styles
(The OO in COOL)These single-purpose classes allow you to compose multiple components in any number of ways without having to re-declare styles in different contexts.Layout Styles
Rather than using a generic 12-column grid, a number of pre-defined layouts are provided (using CSS grid) that can be used to organize pages of content.
Along with Andy Bell’s CUBE CSS, it feels like a next-gen methodology. It’s not just Nicole Sullivan’s thinking on OOCSS styles, or Jonathan’s Snooks thinking on SMACSS, or BEM. It uses some or all of that, and has opinions both wider (overall layout) and narrower (how to reset) as well.
Gotta say, feels pretty good to have a website with CSS in the name during these lucrative times.