A really deep dive into flexbox. This is a great example of what I categorise as “thinking like a browser” (a skill I recommend for any front-end developer).
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.
Let the power of the browser work for you, and use less stuff!
Your websites start fast until you add too much to make them slow. Do you need any framework at all? Could you do what you want natively in the browser?
Damn, I wish I had thought of giving this answer to the prompt, “What is one thing people can do to make their website better?”
If you do nothing else, this will be a huge boost to your site in 2022.
Chris’s piece is a self-contained tutorial!
So when it comes down to the root of the problem, perhaps it isn’t CSS itself but our unwillingness to examine our sexist ideas of what is worthy in web development.
This is a smart collection of situations to consider and the CSS to resolve them. It’s all about unearthing assumptions.
This is a wonderful piece by Bram. Half history lesson, and half practical advice for building resilient websites today:
By embracing what the web platform gives us — instead of trying to fight against it — we can build better websites.
Keep it simple. Apply the Rule of Least Power. Build with progressive enhancement in mind.
If I were to point out one thing that people can do to make their website better, it is to take a moment to think about the most crucial actions that we want our users to be able to do on a page and make them as easy and accessible as possible.
All visual effects, fancy graphics, beautiful interactions, and tracking scripts should come second.
Wise words from Anna.
I hope that progressive enhancement doesn’t become yet another buzzword and that you really take a moment to help the user accomplish what they came for.
Eric’s response to Chris’s question—“What is one thing people can do to make their website better?”—dovetails nicely with my own answer:
The two real problems here are:
- Third-party assets, such as the very analytics and CRM packages you use to determine who is using your product and how they go about it. There’s no real control over the quality or amount of code they add to your site, and setting up the logic to block them loading their own third-party resources is difficult to do.
- The people who tell you to add these third-party assets. These people typically aren’t aware of the performance issues caused by the ask, or don’t care because it’s not part of the results they’re judged by.
Chris is doing another end-of-year roundup. This time the prompt is “What is one thing people can do to make their website bettter?”
This is my response.
I’d like to tell you something not to do to make your website better. Don’t add any third-party scripts to your site.
I like this high-level view of the state of CSS today. There are two main takeaways:
- Custom properties, flexbox, and grid are game-changers.
- Pre- and post-processers are becoming less and less necessary.
This is exactly the direction we should be going in! More and more power from the native web technologies (while still remaining learnable), with less and less reliance on tooling. For CSS, the tools have been like polyfills that we can now start to remove.
They could learn a thing or two from the trajectory of CSS: treat your frameworks as cattle, not pets.
Prompted by my post on tracking, Chris does some soul searching about his own use of tracking.
I’m interested not just in the ethical concerns and my long-time complacency with industry norms, but also as someone who very literally sells advertising.
He brings up the point that advertisers expect to know how many people opened a particular email and how many people clicked on a particular link. I’m sure that’s right, but it’s also beside the point: what matters is how the receiver of the email feels about having that information tracked. If they haven’t given you permission to do it, you can’t just assume they’re okay with it.
I like this approach to reading widely and staying up to date enough.
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.
New principle: Do not design around third-party tools unless it actually breaks the Web · Issue #335 · w3ctag/design-principles
There’s a really interesting discussion here, kicked off by Lea, about balancing long-term standards with short-term pragmatism. Specifically, it’s about naming things.
Naming things is hard. Naming things in standards, doubly so.
It sometimes feels like we end up testing the limitations of our tools rather than the content and design itself.
What Benjamin found—and I heartily agree—is that HTML prototypes give you the most bang for your buck: