Shame.css | Hacker News Reader

Shame.css

csswizardry.com

243 pointstomse55 comments

Been doing this for years. I usually call the file ie8.css, though.

I usually hate to leave low content replies on this site, but this comment had me literally laughing out loud. Good show.

LOL! Wow.

I was trying to think of the last time I had to use !important or similar and sure enough it's in my IE specific stylesheet

You're lucky, I've been having to increase the shame by having an ie7.css as well.

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.

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.

> implies that your codebase is a steaming pile of shit.

You went slightly overboard there I think.

It's possibly called shame because the style sheet is public, _it shames the author_.

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."

how about bandaids.css or kludge.css? Get out of the psychology and name the noun.

I'm calling it hax.css

At where I work, we call it chance_2_buy_lunch.scss

Every Friday, we pick 3 random lines from chance_2_buy_lunch.scss (and another 3 from chance_2_buy_lunch.coffee) and the writers of those lines have to buy lunch for the rest of the team.

I understand it differently: they are ashamed of the code (its ugly), but not feeling guilty, since there are no alternatives at the moment...

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.

[1]: https://en.wikipedia.org/wiki/Shame_society

[2]: https://en.wikipedia.org/wiki/Guilt_society

Interesting. The anthropological and psychological definitions aren't really at odds with each other. When you face primarily external disapproval, it's natural to feel "I am bad", because people's outside opinions are not something you can control. When you face internal disapproval, the natural response is "I did something bad", because you know your own reasoning, you have control over it, and you can resolve to do better next time. Same basic principle as "growth mindset vs. fixed mindset". [1]

I'd argue that if devs shame each other all the time, something about your culture is broken. Why? Because the normal response to shame is to want to hide it. You see that in the description of shame vs. guilt societies in the links you provided, where "Shame cultures are typically based on the concepts of pride and honour, and appearances are what counts, as opposed to individual conscience in guilt cultures." Shame is positively correlated with depression, addiction, violence, aggression, bullying, and all sorts of other nasty stuff; guilt is inversely correlated with all of them. [2]

[1] http://mindsetonline.com/whatisit/about/

[2] http://www.youtube.com/watch?v=psN1DORYYV0#t=840

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!"

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!

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.

Hacks.css sounds nicer than shame.

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'd go with dirtyha.css

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.

[1] http://www.quirksmode.org/css/csshacks.html

This is a really indirect and complicated alternative to putting FIXME comments into the source.

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.

This is particularly easy to do in CSS because it is built up out of a set of rules that have no particular ordering or context. In a way, that's the beautiful part about the CSS. You can concatenate the files however you like and you can also pull out pieces from various components into one place. This certainly isn't possible in most programming where code behavior is highly dependent on the context that it is written.

There might be a subtle difference in the way people think about CSS vs. other programming that would push them to one solution or the other.

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.

Personally, I use an Org Mode file, which allows me to organize crufty stuff, design/architecture overview, and future goals all in one place.

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.

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.

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.

I do this, although I just call it `style.css`

> 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.

1. http://en.wikipedia.org/wiki/Broken_windows_theory

Brilliant idea! Best thing I read on HN today.

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:

//TODO HACK HACK HACKITY HACK

few legitimate uses for comments in code

You mean comments in CSS specifically?

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.

I'm pretty firmly in the "code as documentation" camp, what can I say? I think that most of the time, if you can describe an action with two or three words, you probably ought to be extracting that logic into a method by the same name.

IMHO comments are best used in a handful of situations, such as:

1) Marking hacks 2) Explaining unusual, non-obvious sections of code 3) Noting historical reasons for doing something in a non-obvious manner 4) Noting pitfalls to be avoided 5) Making passive aggressive remarks about the "business guy" who made you do something terrible

Not an exhaustive list of course, but I do think that it's best to think twice before writing a comment, asking yourself "how can I make this more obvious with my 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.

My favourite thing about this, that they used a colour called #BADA55

Unfortunately I think most of my CSS would deserve to be in shame.css

Related: is there a good short "remedial CSS for programmers" book or something?

I'm just going to leave here some of my CSS Good Practices bookmarks:

* 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...

Kindly upload shame.css to a github.io page

This could make shame.github.io/shame.css available to all sites at no charge to the users...

Or you could just use a comment.

I know I can search my codebase for HACK and see all of my greatest embarrassments.

I've seen a fair amount of "final code" delivered by vendors with "TODO" comments all over the place.

Another fancy term for this is "keeping track of technical debt". And it's an excellent idea.

Why is overflow hidden a hack?

He didn't say that it was bad by itself, but when used to hide something instead of fixing it:

> "overflow:hidden;" instead of working out what’s actually broken our layout

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.

overflow: hidden; is not a hack. It can do a lot of things which in his opinion are hacks (wtf).

I think he was merely saying that it is a hack in the instance where a proper fix, without using overflow: hidden, COULD be found but in order to fix it NOW it was required to be used.

It's not that overflow: hidden in itself is a hack, but it's application to counter collapsing due to floats. Already in the first paragraph, your link states that float containment is a side-effect. While I do use it for this exact reason, it leaves a bit of an aftertaste. And when it comes to css, isn't that the definition of a hack?

Nice idea. Maybe we should use shame.php and shame.js as well.

Reply on news.ycombinator.com