惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Vercel News
Vercel News
O
OpenAI News
Engineering at Meta
Engineering at Meta
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
月光博客
月光博客
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
WordPress大学
WordPress大学
宝玉的分享
宝玉的分享
GbyAI
GbyAI
T
The Blog of Author Tim Ferriss
Google DeepMind News
Google DeepMind News
B
Blog RSS Feed
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
云风的 BLOG
云风的 BLOG
罗磊的独立博客
S
SegmentFault 最新的问题
The Register - Security
The Register - Security
Hugging Face - Blog
Hugging Face - Blog
D
DataBreaches.Net
U
Unit 42
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog
阮一峰的网络日志
阮一峰的网络日志
P
Proofpoint News Feed
雷峰网
雷峰网
V
Visual Studio Blog
小众软件
小众软件
aimingoo的专栏
aimingoo的专栏
N
Netflix TechBlog - Medium
酷 壳 – CoolShell
酷 壳 – CoolShell
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Y
Y Combinator Blog
博客园 - 【当耐特】
G
Google Developers Blog
L
LangChain Blog
Stack Overflow Blog
Stack Overflow Blog
I
InfoQ
Martin Fowler
Martin Fowler
F
Fortinet All Blogs
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
The Cloudflare Blog
AI
AI
Google Online Security Blog
Google Online Security Blog
Hacker News - Newest:
Hacker News - Newest: "LLM"
博客园 - Franky
Blog — PlanetScale
Blog — PlanetScale
Webroot Blog
Webroot Blog
PCI Perspectives
PCI Perspectives
爱范儿
爱范儿
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org

CSS Wizardry

Front-End’s Missing Metric: The TBT Window Meet Your Users Where They Are with Obs.js Better Browser Caching with No-Vary-Search font-family Doesn’t Fall Back the Way You Think What Is CSS Containment and How Can I Use It? When All You Can Do Is All or Nothing, Do Nothing Obs.js: Context-Aware Web Performance for Everyone Low- and Mid-Tier Mobile for the Real World (2025) The Fastest Site in the Tour de France Making Sense of the Performance Extensibility API Why Do We Have a Cache-Control Request Header? HTML Is Not a Programming Language… Build for the Web, Build on the Web, Build with the Web Licensing Code on CSS Wizardry A Layered Approach to Speculation Rules Designing (and Evolving) a New Web Performance Score Core Web Vitals Colours The Ultimate Contract Templates for Tech Consultants: Protect Your Business and Get Paid Optimising for High Latency Environments Cache Grab: How Much Are You Leaving on the Table? blocking=render: Why would you do that?! Correctly Configure (Pre) Connections The Three Cs: 🤝 Concatenate, 🗜️ Compress, 🗳️ Cache What Is the Maximum max-age? How to Clear Cache and Cookies on a Customer’s Device The Ultimate Low-Quality Image Placeholder Technique Core Web Vitals for Search Engine Optimisation: What Do We Need to Know? The HTTP/1-liness of HTTP/2 In Defence of DOM­Content­Loaded Site-Speed Topography Remapped Why Not document.write()? Speeding Up Async Snippets Critical CSS? Not So Fast! Measure What You Impact, Not What You Influence Optimising Largest Contentful Paint Measuring Web Performance in Mobile Safari Site-Speed Topography Speed Up Google Fonts Real-World Effectiveness of Brotli Performance Budgets, Pragmatically Lazy Pre-Browsing with Prefetch Making Cloud.typography Fast(er) Time to First Byte: What It Is and How to Improve It Self-Host Your Static Assets Tips for Technical Interviews Cache-Control for Civilians Bandwidth or Latency: When to Optimise for Which ITCSS × Skillshare What If? CSS and Network Performance The Three Types of Performance Testing Getting to Know a Legacy Codebase Image Inconsistencies: How and When Browsers Download Images Identifying, Auditing, and Discussing Third Parties My Digital Music Setup Measuring the Hard-to-Measure Finding Dead CSS The Fallacies of Distributed Computing (Applied to Front-End Performance) Ten Years Old Relative Requirements Airplanes and Ashtrays Performance and Resilience: Stress-Testing Third Parties Refactoring Tunnels Little Things I Like to Do with Git Writing Tidy Code Configuring Git and Vim Base64 Encoding & Performance, Part 2: Gathering Data Base64 Encoding & Performance, Part 1: What’s Up with Base64? Code Smells in CSS Revisited Typography for Developers Moving CSS Wizardry onto HTTPS and HTTP/2 Ack for CSS Developers A New Year, a New Focus Preparing Vim for Apple’s Touch Bar Choosing the Correct Average CSS Shorthand Syntax Considered an Anti-Pattern CSS Wizardry Newsletter Nesting Your BEM? Improving Perceived Performance with Multiple Background Images Continue Normalising Your CSS Pure CSS Content Filter Pragmatic, Practical, and Progressive Theming with Custom Properties Refactoring CSS: The Three I’s Speaker’s Checklist: Before and After Your Talk Improving Your CSS with Parker The Importance of !important: Forcing Immutability in CSS Mixins Better for Performance Managing Typography on Large Apps White October Events Workshop Partnership BEMIT: Taking the BEM Naming Convention a Step Further Travelling Like You Want to, When You Have To Contextual Styling: UI Components, Nesting, and Implementation Detail Subtleties with Self-Chained Classes Cyclomatic Complexity: Logic in CSS Immutable CSS Can CSS Be Too Modular? More Transparent UI Code with Namespaces When to use @extend; when to use a mixin The Specificity Graph CSS Wizardry Ltd.: Year 1 in review
You know your context – on critical thinking and thinking for yourself
Harry Roberts · 2013-01-30 · via CSS Wizardry

Written by on CSS Wizardry.

Table of Contents

Independent writing is brought to you via my wonderful Supporters.

  1. Featured case study: NHS

I’ve long shied away from subjective, opinion style articles for two main reasons; firstly, I’m not one to think that people actually care what’s on my mind and secondly, they seem to do more harm than good. When there are opinions flying about the last thing you want to be adding is further opinion.

Today, however, I’m breaking that rule a little, as this is something that does affect me a lot, and not something that I’m aware people have discussed before.

Before I go any further, though, I must state clearly that this isn’t a criticism of my readers, or anybody else. This is merely an observation.

There seems to be a problem – and I’m sure it’s not exclusive to our industry – where people just don’t seem to think for themselves. Time and again people write blog posts explaining abc and people will constantly ask what about xyz?

Instead of taking the knowledge that the author has imparted and applying it to their context, they will put that responsibility on the author’s shoulders. People aren’t thinking for themselves.

The two most recent examples, for me, were me advising completely against the use of IDs in CSS, and for the use of a background image for your logo.

In the first case, I had questions like what if you can’t touch the markup and it only has IDs in it? In this case, you obviously can’t avoid IDs; this is your context which is away from the norm. This isn’t a problem with the advice per se, but rather an unexpected situation which requires some extra thought on your part. Using some critical thinking, and thinking for yourself, it is easy to deduce that hey, I get the point he’s making, but I can’t do it myself because of my situation…

Featured case study: NHS

How I helped the NHS rapidly build a brand new product.

Read case study…

If you can’t avoid using IDs, or you simply don’t want to then don’t; no one is forcing you to, merely offering up advice that you can take or leave provided you have done enough critical thinking to make an informed decision. Imagine the following scenario:

I’m searching the internet to try and find a new meal to try cooking. I find a recipe which says to use mushrooms… now, I hate mushrooms, so what do I do?

  1. Leave a comment on the article along the lines of OMFG what if you don’t like mushrooms?! This recipe doesn’t work if you don’t like mushrooms!!!
  2. Find a recipe that doesn’t involve mushrooms, one that better suits my context?

I think it’s pretty clear that if I were to do #1, I’d get a big ol’ WTF from the author. I should think for myself here, consider my needs and my context to reach an informed decision for myself. It’s not the author’s fault that my circumstances are different to the ones they wrote for.

The second occurrence – with the background image – I had a lot of people saying that the logo won’t be printable now or Google Image results won’t show my logo. Both of these are true, so if you need these features then don’t use the background image method. You need to take external knowledge, from an article for example, and combine it with your knowledge of your situation to come up with the best solution to your problem.

Things are often written with one, known context in mind; if you’re throwing the curveballs then the onus is on you to think about them for yourselves, and share any thoughts of findings you arrive at. We need to think for ourselves.

I would like to reiterate that this is not a criticism of anyone; we all do it, myself included! Often I’ll see something and my first thought might be this would never work on a big site…, then I realise what I’m doing, and my second, more conscious thought is perhaps it won’t work on a big site, but perhaps that’s not the intended context….


New ideas and methods should be examined, questioned and rigorously tested, but if you’re the one with the unusual circumstances or the different context then consider doing your own testing, rather than passing it back to the original author with an air of ‘doesn’t work’.

It is impossible – as an author – to consider and cover every possible scenario that a bit of advice might find itself in. If you were to try then articles would lose any conviction; instead of try abc if you want xyz you’d soon end up with try abc if you want xyz, but not in this situation, or this situation, or this one, or this one…. Articles would soon become very verbose and the whole point would often get lost.

This isn’t a criticism of people, by any means, but I am hoping to draw attention to something that I’m sure I’m not alone in experiencing. As a developer who frequently writes on the subject of ‘new’ attitudes to front-end builds (no IDs, more classes, presentational class names etc) it often means that the next few days after publishing anything I am firefighting people who dismiss an entire school of thought because it didn’t work in their context.

I honestly feel it’s something we all need to get better at; instead of leaping in with our first reaction in a bid to prove someone or something wrong, try considering your context applied to the advice, consider that perhaps the author didn’t think about situations like yours, or that the advice simply isn’t for people in situations like yours. Perhaps it’s just obvious that you can’t use a piece of advice, but don’t take that as meaning the advice is bad, perhaps it’s just not suitable for you right now.

I’m definitely trying my hardest to be a little more objective about things like this lately, it’s a hard habit to shake, but I believe we all need to try and apply some critical thinking to any advice we encounter.