Sure, this is just an illustration. I hear Eric Meyer's normalization css was too -- more intended as a to-do list of elements you might want to consider reseting than something to include and then override. But then a lot of people ran with the idea of leveling all margins and padding with a global override to start with and then overriding that override (usually inadequately).
Of course, the horse is out of the barn on the personal $ library front, so maybe Irish doesn't have to worry about inadvertently influencing people badly. There already was a no-library/micro-library trend 4-5 years ago where lots of people would write their own tiny jQuery-like DOM utilities, and I've worked on a few projects where someone used jQuery-like idioms for their partial reimplementation (I call them "nayQuery"). Even the better ones are a pain where they subvert expectations. And of course, when someone later decides to add jQuery to the project (makes sense, jQuery does more and has an ecosystem around it), now you're using $ for the custom library and jQuery for jQuery, which is disorienting.
I've written my own version of what Irish presents here -- it's a useful exercise, I appreciate his contribution (helps me think about some different ways to approach it), and sometimes it's even concretely useful when you're getting started on a small project with a limited browser target where the rest of the codebase is going to be smaller than jQuery itself.
But when I write something like this, I always name it differently than $.
Of course, the horse is out of the barn on the personal $ library front, so maybe Irish doesn't have to worry about inadvertently influencing people badly. There already was a no-library/micro-library trend 4-5 years ago where lots of people would write their own tiny jQuery-like DOM utilities, and I've worked on a few projects where someone used jQuery-like idioms for their partial reimplementation (I call them "nayQuery"). Even the better ones are a pain where they subvert expectations. And of course, when someone later decides to add jQuery to the project (makes sense, jQuery does more and has an ecosystem around it), now you're using $ for the custom library and jQuery for jQuery, which is disorienting.
I've written my own version of what Irish presents here -- it's a useful exercise, I appreciate his contribution (helps me think about some different ways to approach it), and sometimes it's even concretely useful when you're getting started on a small project with a limited browser target where the rest of the codebase is going to be smaller than jQuery itself.
But when I write something like this, I always name it differently than $.