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?
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.
Jim mashes up Ilya Grigorik’s book High Performance Browser Networking with my talk on the layers of the web and Nassim Taleb’s idea of antifragility.
This is such a great clear explanation from Lynn on how to add some tasteful parallax depth to scrolling pages.
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.
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.
Yes, I’m a sucker for pace layers, but I think Rich is onto something here, mapping a profession onto a pace layer diagram.
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.
Once you start getting into interactive website territory, with API calls and fancy stuff, that’s where you need JavaScript (JS) knowledge. More specifically, vanilla JS: plain JS with no additional frameworks or plugins. The JS that your browser understands without having to do any pre-processing. It makes working with frameworks a whole lot easier, and it’ll help you to know when not to use a framework (and avoid making users download massive JS bundles when all you need is a tiny bit of code).
Out of all of these metaphors, the two most enduring are paper and physical space.
I like this mashup of two diagrams: Stewart Brand’s pace layers and Stephanie DiRusso’s typology of design thinking.
A great talk from Dave on web components:
I think if you were using Web Components before 2020 you were an early adopter and you probably have some scars to show for it. But in 2021, now that all modern browsers support Web Components, I think they’re worth investigating. They have one superpower that no other JavaScript framework offers called the Shadow DOM which is both powerful but frustrating. But another superpower — the power I’m most excited about — is that you can use them standalone without any frameworks, build tools, or package managers.
The talk makes a callback to my talk Building from a few years back. I like that. It feels like a long thoughtful converstation.
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.
I spend most of my time in the application layers—HTML, CSS, and JavaScript—so I fascinating to dive below the surface and learn about the upcoming HTTP/3. Sounds like it’s really more of a change to how things have always worked with the TCP protocol, still chugging away since it was created by Bob Kahn and Vint Cerf.
We may not live in the best of all possible worlds, but we have dodged some bullets:
In the annals of environmental history, humanity’s response to the ozone crisis stands out as a rare success story. During the 1970s and ‘80s, evidence started to mount that certain household chemicals used in refrigerators, air conditioners, and aerosol cans like hairspray were eating a giant hole in Earth’s ozone layer, which prevents harmful ultraviolet radiation from reaching the surface. Facing the terrifying prospect of a future without any atmospheric sunscreen at all, in the late 1980s nations came together to sign the Montreal Protocol, a global treaty to phase out so-called ozone-depleting substances like chlorofluorocarbons.
But if things hadn’t turned out that way—if the scientific evidence linking man-made chemicals to ozone depletion wasn’t strong enough, or if ozone deniers (yes, there were ozone deniers) successfully stymied the Montreal Protocol—the world might look very different.
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.
Katie shared this (very good) piece about service design on Slack at work today, and when I got to the bit about different levels, my brain immediately went “pace layers!”
- The Service
- The Infrastructure
- The Organisation
- The Intent
- The Culture
Here’s the video of the talk I gave at the Web Stories conference back in February.
This old article from Chris is evergreen. There’s been some recent discussion of calling these words “downplayers”, which I kind of like. Whatever they are, try not to use them in documentation.
Looking at COVID-19 through the lens of pace layers.
…a citizen could actually play a part that was as important as a vaccine, but instead of preventing transmission of the virus into another cell at the ACE receptor level, it’s preventing transmission of the virus at the social network level. So we’re actually adopting a kind of behavioral vaccine policy, by voluntarily or otherwise self-isolating.
I love how Remy explains front-end development to his kids:
The bones are the HTML. Each bone has a name, we call them tags (or elements).
…the skin and the paint on the skin, this is CSS.
Finally, the brain and behaviour, the way the website can be interacted with is using the third layer: JavaScript.