views:

112

answers:

6

Are there any good articles on naming comprehensive naming conventions?

I'm looking to clean up some code... everything from assets to models (Codeigniter) to HTML and CSS.

I'm also curious how to structure the CSS... is it better to give everything a unique class ie search-bar-icon or is it better to repeat classes like .search span.icon {?

Thanks, Walker

A: 

Giving each thing a unique id makes your selectors fastest, but bloats your markup and can become a bog to work with. Using unique classes kind of doesn't make sense (classes are used for groups of objects).

Your second option is the cleaner code wise but the selectors are usually significantly slower.

BioBuckyBall
+2  A: 

In HTML/CSS, the id and class selectors are not equivalent. The id carries more weight, so it should be used sparingly. Use it for sections of a page where you have descendant selectors whose class names are the same as other sections but you wish them to be styled differently. Think of the id like a poor man's namespacing for page regions.

Robusto
I like the *a/the* -way of thinking about IDs and classes in HTML. An element with an ID is *the* (id), while one with a class is *a/an* (class). It makes sense, it's easy to follow and it's sortof clean and elegant.
Arve Systad
A: 

Giving literally everything a unique class in your CSS defeats the purpose of "Cascading" style sheets. Effective CSS leverages the cascade so that you're repeating as little styling effort as possible.

Bear in mind that most HTML elements can be styled directly. I don't need to use <span class="something"><label>... because I can style the label itself without using a span. Most people use far more divs and spans than they really need to.

You can also style by inference. For example, I might have an <H3 class="searchResults"> followed by a UL of search results that I want to style uniquely from other ULs on the page. Instead of giving the UL a specific class (of, say, "searchResultsList") I could just use the following rule:

H3.searchResults + ul {some styling...;} or H3.searchResults + div > * {some styling...;}

As for CSS organization, I find it helpful to organize my files by categories of elements, starting with the simplest and most ubiquitous cases, like a, p, etc. and then handle more complex elements like tables later. I group everything by specificity, because that's part of the cascade rules. An element is handled first in its order of appearance in the file, and then by how specific a rule affecting it is. I place all my one-instance and utility classes last (.iconWhichAppearsOnceEver, .noBordersTable, etc.)


body{}
a {}
p {}
h1,h2,h3,h4,h5,h6 {}
h3.searchResults {}
...
table {}
thead {}
thead th {}
thead th a {}
thead th.noFill a {}
...
Superstringcheese
A: 

It fully depends on what you think is best. Conventions aren't rules, they're guidelines that can make your life easier. Codeigniter has relatively strict naming conventions due to the way it loads all the required classes.

For example, the filename of a controller is lowercase but the classname is capitalized and should match the filename. E.g. test.php would results in a class named Test.

Naming HTML classes/IDs is something that isn't standardised and fully depends on what you think is best. I usually try to give my IDs and classes a name that makes sense. For example, a DIV containing a logo will be named "site_logo". A DIV containing a blog article will be named "article", and so on.

Also, don't let the whole "IDs/classes are slower" thing fool you as the speed increase is very small. If you want to optimize your website you'd be better off optimizing your PHP or CSS code than removing HTML IDs or classes.

Yorick Peterse
A: 

Remember that you can stack and inherit CSS classes, as follows:

.icon { background: left center no-repeat; padding-left: 20px; /* leave space for icon */
#SearchBar .icon { background-image: url(../images/icons/search.png); }

A nice technique I've used before is setting multiple CSS classes (in this case, for displaying an audit log):

/* the icon is displayed by each entry; if it has no other class,
   it will show a "generic" icon */
.log .entry {
    padding-left: 20px; /* leave space for icon */
    background: url(../images/icons/log-generic.png) top left no-repeat;
}

/* slot a generic delete icon in */
.log .icon.delete {
    color: red;
    background-image: url(../images/icons/log-delete.png);
}

.log .icon.delete.person {
    background-image: url(../images/icons/log-delete-person.png);
}

This is a great way to define a series of generic styles (for links with icons, toolbar buttons, avatars, etc), which you can then override in specific instances (think of it as class inheritance).

I'm a bit weird about naming in CSS, but I stick to the convention that UpperCase is for IDs, and lowerCamel for classes. It just helps me to differentiate.

The zen of CSS naming that I follow is:

  • The fewer IDs, the better
  • IDs should be reserved for main layout sections
  • ...and to identify elements for DOM/AJAX operations
  • Use generic class names (log, icon, person, button, etc)
  • ...then combine them with IDs or parent classes to form specifics, e.g. #Header a.icon.person for a profile link in the header

Most importantly, keep it lean. The less CSS, the better - use generic, re-usable styles, and you will benefit from a) consistency in your UI, and b) less page bloat.

HTH

Keith Williams
A: 

The entire point of working with classes is so you can use them several times. For CSS specificly for a certain element you should use id's. As said, the less CSS code the better.

Sled