Pedantry: can we call it "guilt.css" instead? In psychological literature, guilt is defined as the "I did something bad" emotion, shame is the "I am bad" emotion. The crucial difference between them is that guilt can be fixed by making amends. That seems like exactly the mindset you want to encourage with this: guilt.css implies that you feel guilty about all the hacks you have and want to make amends, while shame.css implies that your codebase is a steaming pile of shit.
I don't know about psychological literature, but in common usage where I'm from, "guilt" is what you feel when you know you've done something you shouldn't, whereas "shame" is what you feel when you believe others either do or will frown on something. In that context, I think "shame" is more appropriate — essentially, it's a collection of code that brings some degree of shame to the project, not code that you should feel guilty for writing. Think, "It's a shame I had to resort to this."
I also don't know the psych lingo, but I thought right away of the anthropological distinction between cultures of shame[1] (external disapproval from other people) and guilt[2] (internal disapproval from self). On that score, either could work: shame is certainly appropriate here since devs shame each other all the time.
On that line, I agree, but I think the delineation is more precisely between personal and socially induced "feeling bad". I feel like "shame" connotes a social, or at least, public feeling of ostracizing or sadness.
Regardless, I would agree that guilt.css would have less of a deterrent effect (think chocolate), and illustrate the premise more effectively.
Or perhaps we could use i18 to detect whether the coder lives in a Guilt- or Shame-based culture, and dynamically load guilt.css or shame.css based on the results!
yea it's common to say guilt is feeling bad for _something you did_ while shame is feeling bad for _something you are_. But I actually like the use of shame here because it's a light hearted self-deprecating jab announcing "I'm a bad coder." I also think the externalization aspect lies in favor of shame i.e. "hide your shame!"
We have the same thing in Javascript, we call it 'hacks.js'. That's the place you go when things are broken and you're not yet ready to pay down tech debt.
One key difference here for me is that the word "hacks" might imply that the addition of hacks to that file are acceptable; where as the word "shame" implies that the hacks are less than acceptable and should be used as a last resort.
I would normally agree with you, but the term "hack" in css already has a relatively well defined meaning as "goofy piece of CSS to work around a browser bug"[1]. While I do think it's appropriate to isolate such things so you can remove them when you stop supporting a browser, I don't think they'd belong in a shame.css file. Then again, maybe that's just getting too fetishistic about organizing code.
I find that I rarely fix things marked with FIXME comments. I've had much better success with a 'throwaway.css' file. The idea that a client would load a file with that name on a finished product is distasteful enough for me to want to revisit those hacks.
I don't think it's either indirect or complicated. It's just a file concentrating the FIXME instances that would otherwise be scattered and require a project-wide search.
Simple and elegant imho. That said, I wouldn't use something like that in a project without a build step that merge stylesheets together.
There was a similar idea floated by Yehuda Katz by putting a "cruft" file in a source-code repository that lists all the crufty things that need to be taken care of.
Personally I like it, while some people like putting TODOS in the code (and I do it as well) having a specific cruft file (or shame.css) allows you to put in non-code related stuff and comments at a more over-arching level.
The idea itself sounds good and recognizes what tends to happen especially later in a project. There a number of challenges though:
- The name - as already has been raised by others implies that you have done something wrong.
- Adding to the file requires a degree of confidence and maturity among your team and a level of trust among the group.
- The existence of such a file might reduce effort on the part of some. After all if "shameful" hacks are OK, why bother with real solutions?
- Internal refactoring as an separate independent initiative is sometimes difficult to justify from a financial or political perspective.
In a group with self-aware, well educated, and motivated developers, these concerns might be rather small. But in many larger organizations (with practices that sometimes make Dilbert comics appear tame), this would not work as well for these and other related reasons.
Don't get me wrong, I really like the idea. And since css code is relatively "free" to be included in an arbitrary file, calling out questionable code in this way does seem to have its merits. Perhaps its the use of the term shame that tips me off, but that is a concept that is understood very differently by different people and different cultures. So - like many suggestions - it might work well depending on your group, but is unlikely to be adopted as a universal best practice.
This is a great idea and to be honest the only time I ever use hacks is when I am adding in compatibility for IE8. I disagree with the !important declaration though. I use LESS for writing CSS and while it's definitely a valuable asset to have, the ability to nest and have super specific queries generated means when you'e writing media queries, you sometimes don't want to have to replicate the nesting and specificities instead of just going .element and using !important instead saves time and space. Why is everyone so against using !important? Sometimes when you're overriding CSS added to an element via Javascript you have to use !important, regardless of how specific you are.
Cool idea, but considering IE8 support is on its way out from developers what hacks are left we need to use? Using overflow: hidden instead of resolving a problem is just lazy, it's not a hack, it's plain lazy. Cool idea in theory and perhaps might have been helpful in 2008, but it's 2013 and browsers are all at a point now where we can use CSS and not have to worry about consequences or support except for maybe browser vendor prefixes.
Using !important 9 times out of 10 means you're doing something wrong. Many developers rely on it as a lazy tool for various reasons (bloated unmanageable css files, lack of knowledge, etc.) The media query example and overriding third party code you can't edit are the 1 in 10 examples. I would even possibly debate the media query situation as it is being a bit lazy IMHO.
For me shame.css doesn't necessarily contain hacks. In mine you will find less thought out selectors that are added in haste and anything else that doesn't conform to the high standard I set myself.
> The first bits of bad code set a precedent and make subsequent developers feel less bad about using poor code themselves.
This is really just another manifestation of the "Broken windows theory"[1], which I've witnessed in code many times over. I think it's just a fact of human nature, also similar to the "When in Rome..." adage; it doesn't make you feel nearly as dirty to do something awful (whether it's in code or in a run-down urban environment) when there's already lots of problems to begin with.
I don't like this idea since it separates your hack CSS from the CSS it's supposed to hack. It's an even bigger problem when you're using SCSS and you have to reproduce the entire selector tree for your hacks.
This is a great idea. Too bad code can't really be isolated this way. I feel that marking a hack is one of the few legitimate uses for comments in code:
I feel that marking a hack is one of the few legitimate uses for comments in code
I'll take that as an offhand comment you didn't give much thought to, because wow, there most certainly are lots of legitimate uses for comments in code.
Some of this can/should be done via a CSS system like SASS/Compass. If you're littering overflow:auto into a dozen rules, SASS/Compass would probably help you immensely. When you eventually decide IE6 support isn't needed, flip a single variable and poof--those rules disappear.
You could extend this to a _shame.sass file too, of course.
I'll add another vote for SASS/Compass. That system has saved me tons of heartache and hair-rending (and I don't have the hair to spare). SASS makes it easier to organize your CSS than to leave it unorganized. It almost makes CSS fun.
I think he was referring to those instances where you have something which as far as you can tell at the moment should be a certain height but inexplicably (at the moment, because you need it fixed now!) has this weird margin underneath it. With a quick look at the web inspector and your code you can't work out where it's coming from so in the interests of fixing a problem now, you might `overflow-y:hidden` it with the intent to come back later.
[+] [-] hendrik-xdest|13 years ago|reply
[+] [-] modarts|13 years ago|reply
[+] [-] talmand|13 years ago|reply
[+] [-] ryanmacg|13 years ago|reply
[+] [-] kaws|13 years ago|reply
[+] [-] nostrademons|13 years ago|reply
[+] [-] chc|13 years ago|reply
[+] [-] telemachos|13 years ago|reply
[1]: https://en.wikipedia.org/wiki/Shame_society
[2]: https://en.wikipedia.org/wiki/Guilt_society
[+] [-] ewoodrich|13 years ago|reply
Regardless, I would agree that guilt.css would have less of a deterrent effect (think chocolate), and illustrate the premise more effectively.
[+] [-] bjhoops1|13 years ago|reply
[+] [-] nodata|13 years ago|reply
You went slightly overboard there I think.
It's possibly called shame because the style sheet is public, _it shames the author_.
[+] [-] swah|13 years ago|reply
[+] [-] hashmymustache|13 years ago|reply
[+] [-] randall|13 years ago|reply
Hacks.css sounds nicer than shame.
[+] [-] dansimau|13 years ago|reply
[+] [-] minikomi|13 years ago|reply
[+] [-] awj|13 years ago|reply
[1] http://www.quirksmode.org/css/csshacks.html
[+] [-] ianb|13 years ago|reply
[+] [-] DLarsen|13 years ago|reply
[+] [-] rev087|13 years ago|reply
Simple and elegant imho. That said, I wouldn't use something like that in a project without a build step that merge stylesheets together.
[+] [-] rurounijones|13 years ago|reply
Personally I like it, while some people like putting TODOS in the code (and I do it as well) having a specific cruft file (or shame.css) allows you to put in non-code related stuff and comments at a more over-arching level.
[+] [-] trobertson|13 years ago|reply
[+] [-] EzGraphs|13 years ago|reply
- The name - as already has been raised by others implies that you have done something wrong.
- Adding to the file requires a degree of confidence and maturity among your team and a level of trust among the group.
- The existence of such a file might reduce effort on the part of some. After all if "shameful" hacks are OK, why bother with real solutions?
- Internal refactoring as an separate independent initiative is sometimes difficult to justify from a financial or political perspective.
In a group with self-aware, well educated, and motivated developers, these concerns might be rather small. But in many larger organizations (with practices that sometimes make Dilbert comics appear tame), this would not work as well for these and other related reasons.
Don't get me wrong, I really like the idea. And since css code is relatively "free" to be included in an arbitrary file, calling out questionable code in this way does seem to have its merits. Perhaps its the use of the term shame that tips me off, but that is a concept that is understood very differently by different people and different cultures. So - like many suggestions - it might work well depending on your group, but is unlikely to be adopted as a universal best practice.
[+] [-] DigitalSea|13 years ago|reply
Cool idea, but considering IE8 support is on its way out from developers what hacks are left we need to use? Using overflow: hidden instead of resolving a problem is just lazy, it's not a hack, it's plain lazy. Cool idea in theory and perhaps might have been helpful in 2008, but it's 2013 and browsers are all at a point now where we can use CSS and not have to worry about consequences or support except for maybe browser vendor prefixes.
[+] [-] arcosdev|13 years ago|reply
[+] [-] jaseflow|13 years ago|reply
[+] [-] benhowdle89|13 years ago|reply
[+] [-] k3n|13 years ago|reply
This is really just another manifestation of the "Broken windows theory"[1], which I've witnessed in code many times over. I think it's just a fact of human nature, also similar to the "When in Rome..." adage; it doesn't make you feel nearly as dirty to do something awful (whether it's in code or in a run-down urban environment) when there's already lots of problems to begin with.
1. http://en.wikipedia.org/wiki/Broken_windows_theory
[+] [-] scottporad|13 years ago|reply
[+] [-] psychometry|13 years ago|reply
[+] [-] bjhoops1|13 years ago|reply
//TODO HACK HACK HACKITY HACK
[+] [-] fredoliveira|13 years ago|reply
I'll take that as an offhand comment you didn't give much thought to, because wow, there most certainly are lots of legitimate uses for comments in code.
[+] [-] artursapek|13 years ago|reply
You mean comments in CSS specifically?
[+] [-] eclipticplane|13 years ago|reply
You could extend this to a _shame.sass file too, of course.
[+] [-] drivingmenuts|13 years ago|reply
[+] [-] spacec0wb0y|13 years ago|reply
[+] [-] tlrobinson|13 years ago|reply
Related: is there a good short "remedial CSS for programmers" book or something?
[+] [-] glitchdout|13 years ago|reply
* https://github.com/necolas/idiomatic-css
* http://coding.smashingmagazine.com/2009/04/08/from-table-hel...
* http://engineering.appfolio.com/2012/11/16/css-architecture/
* http://www.stubbornella.org/content/2011/04/28/our-best-prac...
[+] [-] theoa|13 years ago|reply
This could make shame.github.io/shame.css available to all sites at no charge to the users...
[+] [-] Pxtl|13 years ago|reply
I know I can search my codebase for HACK and see all of my greatest embarrassments.
[+] [-] ErikRogneby|13 years ago|reply
[+] [-] mcherm|13 years ago|reply
[+] [-] etherealG|13 years ago|reply
[+] [-] Bockit|13 years ago|reply
[+] [-] Deestan|13 years ago|reply
> "overflow:hidden;" instead of working out what’s actually broken our layout
[+] [-] ggurgone|13 years ago|reply
Suggested reading: http://colinaarts.com/articles/the-magic-of-overflow-hidden/
[+] [-] joetech|13 years ago|reply