Hacker News Reader

Comment by mtoledo | Hacker News Reader

you shouldn't declare your sass variable 'blue'. If it becomes green in the future, you'd have a 'blue = green' assignment. Even 'color1' would be a better name.

View on HN

The two things hard in computer science: cache invalidation and naming things.

I'd say the latter is the more difficult. Nice point.

I've had a hard time deciding on a naming convention for my sass variables, and have sometimes resorted to 'color1' and friends.

Anybody have a method they feel good about and would like to share?

You could use names that make sense in the context of the overall design, e.g. theme_color, horizontal_padding, column_width.

Same as in normal programming, really.

Good advice and I do for non-color related variables.

I guess its hard for me to put names on 3-6 colors that are used in various places on the site. This is probably just because I don't have a good idea going in where I'll be using these colors and I end up using them in places that don't apply to the name given.

For instance, I'll name a variable "background_color" and then I'll want to use it somewhere unrelated.

Don't waste time on this. The easy answer is "choose your names semantically", but that's easier said than done. In the end, your users don't care if your variable is named "blue", "color1", or "color_used_to_represent_user_likes_something"

Semantic markup and CSS is something to strive for, but don't kill yourself trying to get to 100%

if you use it for something unrelated, then set the unrelated thing equal to background_color, but keep them semantically separate.

If you go to http://colorschemedesigner.com/ and hit "Random > Randomize Palette" you'll see that most colors in a theme/palette could be categorized like this:

!theme_primary !theme_secondary !theme_accent

!theme_primary_dim !theme_secondary_dim !theme_accent_dim

!theme_primary_bright !theme_secondary_bright !theme_accent_bright

s/theme/palette/

and if you go to export as html/css you'll get something like this:

  .primary-1 { background-color: #FFDDC2 }
  .primary-2 { background-color: #E5C9B4 }
  .primary-3 { background-color: #DAAA84 }
  .primary-4 { background-color: #FFEBDB }
  .primary-5 { background-color: #FFF6EE }

  .secondary-a-1 { background-color: #FFE6C2 }
  .secondary-a-2 { background-color: #E5D1B4 }
  .secondary-a-3 { background-color: #DAB784 }
  .secondary-a-4 { background-color: #FFF0DB }
  .secondary-a-5 { background-color: #FFF8EE }

  .secondary-b-1 { background-color: #FFCFC2 }
  .secondary-b-2 { background-color: #E5BEB4 }
  .secondary-b-3 { background-color: #DA9684 }
  .secondary-b-4 { background-color: #FFE2DB }
  .secondary-b-5 { background-color: #FFF2EE }

  .complement-1 { background-color: #C2FFFD }
  .complement-2 { background-color: #B4E5E3 }
  .complement-3 { background-color: #84DAD7 }
  .complement-4 { background-color: #DBFFFE }
  .complement-5 { background-color: #EEFFFE }

This is what I'm using for a website I'm building.

    // >> HEADER/FOOTER
    // background color for header/footer
    !nav_background = #5C504F 
    
    // border of header/footer
    !nav_border = #5C504F + #2B2830
    
    // text in header/footer 
    !nav_text = #F0F8FE
    
    // >> BACKGROUND BEHIND CONTENT
    // background between content and nav elements
    !site_background = #2B2830  
    
    // border between background and content
    !site_border = #ABAB8E
    
    // >> CONTENT
    // background for content
    !content_background = #F0F0D8
    
    // table odd row
    !content_lighter_background = #F0F0CA
    
    // text color
    !content_text = #000
    
    // regular links in content
    !content_links = #2B2830
    
    // control links (flag, edit, delete, etc.)
    !content_edit_links = #8B8870
    
    // secondary nav border, section seperator, table header seperator
    !content_seperator = #D9D7A3

Screenshot: http://epochwolf.com/singleforestcom-screenshot

You should declare your sass variable 'blue', because it's easier to work with than #3bbfce. if you want to change it to green, you would change it in the declaration from border-color = !blue to border-color = !green. (Or add an intermediate variable like !primary_color = !blue.)

I think mtoledo's point is that variable names should have context, and not be mere appropriations of their content. For example, "theme_color" would be better than "blue" because you could use it in context among lots of different CSS definitions, and if your theme color changes, it's a single change, as opposed to changing all the "blue"s to "green"s or whatever.

I understood that part, that's why I gave the example of !primary_color. The point I'm making is that naming a variable after a color isn't necessarily a bad thing and can be a useful abstraction, and there's no reason you can't do both. I can recognize some common color hex codes, but I find it easier to work with more human readable names. If I'm looking at a site and I want to make the orange color slightly darker, will I remember that it's !color3? Or is it easier to look through for !light_orange?

I follow you isleyaardvark. I think one of the challenges of having a discussion about CSS is scope/setting. CSS is used on every different type project. If you're doing client work and building 5 page mini site (I'm not suggesting anything), your thoughts on CSS are based on a completely different use than the developer that maintains 500+ pages.

We both know CSS. But we use them entirely differently.

On a site with 500+ pages, by the time you've implemented all of your !blue to !green, or !light_orange to !dark_orange throughout your stylesheets, management will be considering another redesign.

For me, it's easier to inspect the element in Firebug and copy/search the hex code, since I get the guarantee that I'm not changing an unrelated poorly named variable.

I find that for simpler sites, naming colors after their closest tone works well, but when I have a dozen shades of the same color, I start to run out of names very quickly (e.g. it's not unusual for me for a single page to have different background boxes, zebra striped tables, subheaders, selected/hover states and an array of other details on top of the overall layout)

That's why I think names like "color3" are bad. If the orange is on headings, look for headings. If the orange is the page background, look for what represents that. I don't see a compelling reason to actually use the color name in the variable name since things should be easier to look up if the context is taken into account.

If I go through replacing all of the !blue with !green in my files, I might as well replace #0000ff with #00ff00.

Your variable names represent a value, not a color. You should ask yourself what the function of that value is before naming the variable.

But that's just me. CSS is not something you can let slide. Adding templates, widgets, and pages on a mass scale (20+ templates, 30+ widgets, 500+ pages), your CSS deficiencies will show quickly.

I should've said "You should add an intermediate variable" instead of "Or add an intermediate variable". If you were to name a variable !blue, it should be treated like a global variable, and only used in matters of say, the color palette of a site, and not the particular color used in sidebar.

Agreed. I do the exact same thing. First define a palette and with variable names that describe the color (eg, !mauve= #E0B0FF), then assign those to descriptive variable names (eg, !accent_color= !mauve). That way it's immediately clear which colors are being used while also avoiding the need to replace variable names throughout the partials.

Can the same not be accomplished with a comment?

Sure, if you want to leave the same comment in every place you assign a particular hex value to one of the descriptive variables and don't mind changing each of those duplicated hex values if you ever need to tweak the color. Personally, I don't see the benefit of using comments when using variables is already self-documenting and further avoids possible duplication of hex values.

I think you misunderstood me, which is understandable.. I was unclear. The comment question wasn't meant to be combative. I agree and can see the benefit/use.

Thanks for being patient with me while I explore alternative solutions.

Reply on news.ycombinator.com