DIV naming conventions, what do YOU do?

[eclipse]

HI all,

I've just heard a tutorial about not naming DIV's after "Where it appears on the page or how it looks" because where and looks both change. So they decided to try and name it more semantically about the context.

EG: Instead of...

div#left { }
div#right { }
div#big-box { }

we'd try names like...

div#container { }
div#branding { }

div#content { }
div#content_main { }
div#content_sub { }

ul#nav-main { }
div#site_info { }

I'm wondering what you also put in as a DIV "ingredient"? I'm especially interested if you work in a large studio what naming conventions your place of employment might have?

 

[SrWebDeveloper]

Sorry for the long answer, but this is an interesting question and THANK YOU for posting it!

I've learned over the years from programming that you always use very descriptive naming conventions for all variables (in this case, DIV id's and classes) not only so they make sense - but you or someone else could understand its basic meaning and intent if they follow up and debug or modify your code years later. After I've long forgotten the purpose of each name.

These days web layout has migrated slowly from tabular to DIV/CSS layout for a lot of us, and the lingo discussed by W3C and many other sources use derived names such as container, branding, nav, and so on as you listed in your second example set. It's only natural since that's what most of the tutorials say, and it makes perfect sense as well to include common business (i.e. branding) and coding conventions (i.e. containers) in the naming conventions for ID's and classes.

To get specific, here are my general rules I do my best to live by for the reasons I stated in the first paragraph:

• Always use sensible names that "tell the story"
• Use underscores as separator characters, i.e. "nav_left", "nav_right"
• Stick to one case, i.e. upper or lower (I prefer lower) in all selectors
• Always include comments using /* comment */ in your CSS

And I'd like to add on a few more common descriptors:

• header
• footer
• site_map
• main_wrapper
• container_x (where x matches the parent div ID or class or content area name for alignment or sizing purposes)

There are no "in house" rules, it's up to each developer to follow standards and document our code well. Especially since the source ends up in Subversion (CVS) as part of the SCM process. Maybe some places are more anal retentive than where I work, I dunno. But this sums up my general approach and how my workplace expects such things. I don't always follow this on personal projects apart from work but it's a good practice to try! To each their own and it would be interesting to see what other people do -- this is all so subjective, after all. I think what separates the pro's from the joe's is whatever standards are set, they follow them on each project. PM's appreciate it, even if the client doesn't!



-jim

 

[angelwatt]

I always aim at using semantic naming. I have a general ID layout of all, header, nav, content, and footer. Then it's usually classes more than IDs. I make sure whatever the name is, it makes sense even when removed from context. It's why I hate when I see DreamWeaver code and the CSS has a ton of style12, style34, etc., which has no meaning whatsoever.

Using semantic naming makes it easier on yourself when creating styles, locating them in your stylesheet, and also makes it easier on coworkers who you may be working with it. When you use the words top/left/right/etc as part of the names, then you have weird issues if that content changes locations on the page. You'd need to rename all the parts, or keep in mind things are not where they say.

 

[eclipse]

Excellent!

What does "* main_wrapper" mean? What's a "wrapper"?

Cheers.

 

[angelwatt]

Excellent!

What does "* main_wrapper" mean? What's a "wrapper"?

Cheers.

Wrapper is synonymous with container. It's generally a div tag that is wrapped around some content. Nothing very spiffy.

As far as the * that precedes the selector, I believe that's a CSS hack that only gets acknowledged by certain browsers. Another CSS hack page. Here's the better of the CSS hack pages I found with a quick search.

The * selector on its own means any tag, so "* main_wrapper" essentially means any tag named main_wrapper, which isn't a real tag name. Was there suppose to be a . or # before main_wrapper? It's likely directed at IE browsers.

I personally have never used any CSS hacks, because I see no need for them. IE is generally the only browser that needs fixing and it can be done with conditional comments as needed, though I rarely do that as well.

 

[SrWebDeveloper]

Nobody in this topic posted an asterisk within any CSS prior to the OP inquiring about it, I think they might be seeing the list item bullet in my first reply as an asterisk! But thanks for explaining anyway as it is useful to know!

 

[Melrose]

I name mine Gladys, Francine and Hector.

Seriously - If you have to name anything it makes sense to do it in a way it's easy to follow for a developer later.

I use simple conventions, much like you do Jim - except I use inCaps (in place of underscores for what would be spaces); I use underscores as a way of sub-categorizing the elements (if needed) and hyphens for numbering similar items.

eg:
#subNavigation

#leftColumn_top
#leftColumn_middle

.listStyle-1
.listStyle-2

Meh, that's just me.. Whatever you use, having them clearly defined before jumping into a project makes for an easier road to code.

 

[SrWebDeveloper]

@melrose

I think its worth mentioning that in XHTML strict 1.0 the element names in selectors become case sensitive just as it for XML, so one has to be very careful there.

 

[Melrose]

@melrose

I think its worth mentioning that in XHTML strict 1.0 the element names in selectors become case sensitive just as it for XML, so one has to be very careful there.

Exactly - I never use case to differentiate between elements (#divone vs #divOne) but I am nonetheless picky about case just the same, if nothing else than for my own posterity.