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.
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:
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.
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.
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.
Here are the slides from my opening keynote at Beyond Tellarrand on Thursday. They don’t make much sense out of context.
I’m really pleased with how this turned out. I wasn’t sure if anybody was going to be interested in the deep dive into history that I took for the first 15 or 20 minutes, but lots of people told me that they really enjoyed that part, so that makes me happy.
HTML lets you create the structure of a website.
CSS lets you make the website look nice.