Written by Harry Roberts on CSS Wizardry.
N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…
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…
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?
OMFG what if you don’t like mushrooms?! This recipe doesn’t work if you don’t like mushrooms!!!
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.
N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…
Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.
Hi there, I’m Harry Roberts. I am an award-winning Consultant Web Performance Engineer, designer, developer, writer, and speaker from the UK. I write, Tweet, speak, and share code about measuring and improving site-speed. You should hire me.
You can now find me on Mastodon.
I help teams achieve class-leading web performance, providing consultancy, guidance, and hands-on expertise.
I specialise in tackling complex, large-scale projects where speed, scalability, and reliability are critical to success.