This is a terrrific presentation by Chris, going through some practical implementations of modern CSS: logical properties, viewport units, grid, subgrid, container queries, cascade layers, new colour spaces, and view transitions.
Sunday, June 11th, 2023
Thursday, May 4th, 2023
I did an episode of the Clearleft podcast on innovation a while back:
Everyone wants to be innovative …but no one wants to take risks.
The word innovation is often bandied about in an unquestioned positive way. But if we acknowledge that innovation is—by definition—risky, then the exhortations sound less positive.
“We provide innovative solutions for businesses!” becomes “We provide risky solutions for businesses!”
I was reminded of this when I saw the website for the Podcast Standards Project. The original text on the website described the project as:
…a grassroots coalition working to establish modern, open standards, to enable innovation in the podcast industry.
I pushed back on that wording (partly because I’ve seen the word “innovation” used as a smoke screen for user-hostile practices like tracking and surveillance). The wording has since changed to:
…a grassroots coalition dedicated to creating standards and practices that improve the open podcasting ecosystem for both listeners and creators.
That’s better. It’s more precise.
Am I nitpicking? Only if you think that “innovation” and “improvement” are synonyms. I don’t think they are.
Innovation implies change. Improvement implies positive change.
Not all change is positive. Not all innovation is positive.
Innovation goes hand in hand with disruption. Again, disruption involves change. But not necessarily positive change.
Think about the antonyms of change and disruption: stasis and stability. Those words don’t sound very exciting, but in some arenas they’re exactly what you should be aiming for; arenas like infrastructure or standards.
Not to get all pace layers-y here, but it seems to me that every endeavour has a sweet spot for innovation. For some projects, too little innovation is bad. For others, too much innovation is worse.
The trick is knowing which kind of project you’re working on.
(As a side note, I think some people use the word innovation to describe the generative, divergent phase of a design project: “how might we come up with innovative new approaches?” But we already have a word to describe the practice of generating novel and interesting ideas. That word isn’t innovation. It’s creativity.)
Wednesday, April 19th, 2023
Grease is a website starter that makes building performant, accessible, aesthetic websites fast & frictionless.
Interestingly, this starter kit uses cascade layers for managing CSS.
Tuesday, November 15th, 2022
What happens if the ‘pace layers’ get out of sync?
A very thoughtful post by Miriam on how tools can adversely affect the pace of progress in the world of web standards.
When tools intervene between you and your access to the web platform, proceed with caution. Ask not only: How well does it work? But also: How well does it fail? Not only: What features do they provide? But also: What features do they prevent?
Thursday, September 8th, 2022
Dave rounds up some of the acronymtastic ways of scoping your CSS now that we’ve got a whole new toolkit at our disposal.
If your goal is to reduce specificity, new native CSS tools make reducing specificity a lot easier. You can author your CSS with near-zero specificity and even control the order in which your rules cascade.
Sunday, July 17th, 2022
Wednesday, June 29th, 2022
This is such a great clear explanation from Lynn on how to add some tasteful parallax depth to scrolling pages.
Monday, June 20th, 2022
I believe that we haven’t figured out when and how to give a developer access to an abstraction or how to evaluate when an abstraction is worth using. Abstractions are usually designed for a set of specific use-cases. The problems, however, start when a developer wants to do something that the abstraction did not anticipate.
Smart thoughts from Surma on the design of libraries, frameworks, and other abstractions:
Abstractions that take work off of developers are valuable! Of course, they are. The problems only occur when a developer feels chained to the abstractions in a situation where they’d rather do something differently. The important part is to not force patterns onto them.
This really resonated with parts of my recent talk at CSS Day when I was talking about Sass and jQuery:
If you care about DX and the adoption of your abstraction, it is much more beneficial to let developers use as much of their existing skills as possible and introduce new concepts one at a time.
Tuesday, May 24th, 2022
Pace layers and design principles
I think it was Jason who once told me that if you want to make someone’s life a misery, teach them about typography. After that they’ll be doomed to notice all the terrible type choices and kerning out there in the world. They won’t be able to unsee it. It’s like trying to unsee the arrow in the FedEx logo.
I think that Stewart Brand’s pace layers model is a similar kind of mind virus, albeit milder. Once you’ve been exposed to it, you start seeing in it in all kinds of systems.
Each layer is functionally different from the others and operates somewhat independently, but each layer influences and responds to the layers closest to it in a way that makes the whole system resilient.
Last month I sent out an edition of the Clearleft newsletter that was all about pace layers. I gathered together examples of people who have been infected with the pace-layer mindworm who were applying the same layered thinking to other areas:
- Rich applied pace layers to career paths,
- Mark applied pace layers to the design process, and
- Jorge Arango applied pace layers to reading.
Recently I had another flare-up of the pace-layer pattern-matching infection.
I was talking to some visiting Austrian students on the weekend about design principles. I explained my mild obsession with design principles stemming from the fact that they sit between “purpose” (or values) and “patterns” (the actual outputs):
Purpose » Principles » Patterns
Your purpose is “why?”
That then influences your principles, “how?”
Those principles inform your patterns, “what?”
Hey, wait a minute! If you put that list in reverse order it looks an awful lot like the pace-layers model with the slowest moving layer at the bottom and the fastest moving layer at the top. Perhaps there’s even room for an additional layer when patterns go into production:
Your purpose should rarely—if ever—change. Your principles can change, but not too frequently. Your patterns need to change quite often. And what you’re actually putting out into production should be constantly updated.
As you travel from the most abstract layer—“purpose”—to the most concrete layer—“production”—the pace of change increases.
I can’t tell if I’m onto something here or if I’m just being apopheniac. Again.
Monday, March 7th, 2022
This is a terrific analysis of why frameworks exist, with nods to David Hume’s is-ought problem: the native features are what is, and the framework features are what somebody thinks ought to be.
I’ve been saying at conferences for years now that if you choose to use a framework, you need to understand that you are also taking on the philosophy and worldview of the creators of that framework. This post does a great job of explaining that.
Thursday, March 3rd, 2022
Yes, I’m a sucker for pace layers, but I think Rich is onto something here, mapping a profession onto a pace layer diagram.
Monday, January 3rd, 2022
I’d recommend going in the order HTML, CSS, JS. That way, you can build something in HTML, add CSS to it as you learn it, and finally soup it up with your new-found JS knowledge.
Excellent advice for anyone new to web develoment.
Sunday, January 2nd, 2022
Out of all of these metaphors, the two most enduring are paper and physical space.
Thursday, November 18th, 2021
I like this mashup of two diagrams: Stewart Brand’s pace layers and Stephanie DiRusso’s typology of design thinking.
Tuesday, October 19th, 2021
A great talk from Dave on web components:
The talk makes a callback to my talk Building from a few years back. I like that. It feels like a long thoughtful converstation.
Monday, September 20th, 2021
This is a really in-depth explanation from Bramus of the upcoming
@layer rules in CSS, from the brilliant minds of Miriam, fantasai and Tab.
Basically, you’ll be able to scope styles, and you get to define the context for that scoping. So all those CSS-in-JS folks who don’t appreciate the cascade will have a mechanism to get encapsulated styles.
I can see this being very handy for big complex codebases with lots of people on the team.
Tuesday, August 10th, 2021
Tuesday, May 11th, 2021
The more I consume content in reading apps, the more I am reminded of the importance and the power of progressive enhancement as a strategy to create resilient and malleable experiences that work for everyone, regardless of how they choose to consume our content.
Top stuff from Sara here!
We have a tendency to always make an assumption about how our readers are reading our content—probably in the browser, with our fancy styles applied to it. But if we make a habit out of thinking about the Web in layers and CSS as an enhancement on top of the content layer, then we can start optimizing and enhancing our users’ reading experiences regardless of their context.
Thinking about the different ways in which users access the Web only shines light on the importance of a progressively enhanced approach to building for the Web. The more we think about the Web in layers and try to improve the experience of one layer before moving to the next, the more resilient experiences we can create. That’s what the essence of progressive enhancement is about.
Thursday, April 22nd, 2021
Monday, April 12th, 2021
Here’s the video of the talk I gave at the Web Stories conference back in February.