

Shame.css - tomse
http://csswizardry.com/2013/04/shame-css

======
hendrik-xdest
Been doing this for years. I usually call the file ie8.css, though.

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

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

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

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

~~~
joshbetz
I'm calling it hax.css

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

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

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

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

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

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

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

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

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

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

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

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

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

------
scottporad
Brilliant idea! Best thing I read on HN today.

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

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

~~~
fredoliveira
_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.

~~~
bjhoops1
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?"

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

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

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

------
tlrobinson
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?

~~~
glitchdout
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://coding.smashingmagazine.com/2009/04/08/from-table-hell-to-div-hell/)

* <http://engineering.appfolio.com/2012/11/16/css-architecture/>

* [http://www.stubbornella.org/content/2011/04/28/our-best-prac...](http://www.stubbornella.org/content/2011/04/28/our-best-practices-are-killing-us/)

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

------
Pxtl
Or you could just use a comment.

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

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

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

------
etherealG
Why is overflow hidden a hack?

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

Suggested reading: <http://colinaarts.com/articles/the-magic-of-overflow-
hidden/>

~~~
Beekon
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?

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

