And yes, there needs to be a structured and scheduled review and cleanup otherwise it becomes a nightmare. We do this every 3 months along with scouring the codebase for TODO's and FIXME's. It's done in mob-programming style with drinks which makes for a lot of fun and a good way to share our "mistakes". But to be honest, it's starting to devolve into a "coding roast" of sorts!
Years ago on a large project with many trainee and junior contributors, I had a sandbox.css as the last css file.
Juniors could try out new things and add in naive fixes for bugs. Then in code review we brought the change up into the cascade as a method of teaching cascade thinking.
It's rare to do that now as most front end devs are not interested in the cascade and use things like BEM instead. I can understand why - it's pragmatic - but I did personally find that a great way of building up devs who really grasped css on its own terms.
Comments
Agreed. I've been using the idea of a "shame file" in css as a dumping ground for this sort of thing.
It was brought to my attention by this post https://csswizardry.com/2013/04/shame-css/
And yes, there needs to be a structured and scheduled review and cleanup otherwise it becomes a nightmare. We do this every 3 months along with scouring the codebase for TODO's and FIXME's. It's done in mob-programming style with drinks which makes for a lot of fun and a good way to share our "mistakes". But to be honest, it's starting to devolve into a "coding roast" of sorts!
Years ago on a large project with many trainee and junior contributors, I had a sandbox.css as the last css file.
Juniors could try out new things and add in naive fixes for bugs. Then in code review we brought the change up into the cascade as a method of teaching cascade thinking.
It's rare to do that now as most front end devs are not interested in the cascade and use things like BEM instead. I can understand why - it's pragmatic - but I did personally find that a great way of building up devs who really grasped css on its own terms.