Best Practice for Naming the Id Attribute of Dom Elements

Question

This is related to naming conventions for a DOM element's id attribute and I guess the name attribute as well. When it comes to JavaScript, from what I understand and have done is always use camel case except for the names of classes. Classes are Pascal cased.

Having said that I develop in ASP.NET mainly and here's where I run into a naming issue for the id attribute. In ASP.NET if you drag and drop a new server control to a page(which I rarely do, I'm a type the markup kinda guy), the default names are always Pascal cased because they need to conform to the .NET framework naming guidelines for server-side code.

So when it comes to naming the id attribute of ASP.NET server controls or just elements in markup, I follow the rule to camel case the id attribute (JavaScipt naming guidlines), but this conflicts with the .NET naming guidlines.

So, one, what casing do you folks normally do for the id attribute in DOM elements and two what do the .NET folks who develop in ASP.NET do for naming the id attribute?

On top of that when I'm creating form elements in markup, I generally use Hungarian notation for text inputs, like

<input type="text" id="txtUserName" />

or for checkboxes like

<input type="checkbox" id="chkSelectAll" />

Which definitely goes against .NET server-side code naming guidelines and maybe JavaScript guidelines as well.

Any advice is much appreciated.

Answer 1

Here are some naming guidelines that have helped me out with my ids and classes in the DOM:

• don't include the type in the name (ie, no txt or chk). I can select that info using CSS or jQuery much more descriptivlely
• use underscores as separators in the name. Hyphens don't always work out in other languages, and camel casing is a little tough to read in markup

Answer 2

One of the HTML gurus at my last job actually recommended delimiting multi-word IDs with dashes

<input type="text" id="user-name" />

I'm struggling to remember why - I don't have access to those internal standards documents anymore. I know that really doesn't answer your question about Pascal vs Camel casing, though.

I'd personally advise against using HN - I find it to be a largely abhorrent practice. What happens if you need to change your checkbox array to a select element instead? Now the element's ID has false semantics baked-in. It's just not worth the hassle, IMO.

Answer 3

• Keep it semantic. Use complete, simple, (preferably English) words. Don't try to come up with something fancy or technical, and don't describe what it is - we know that. Describe what it does. Describing purpose adds informational value.

• Don't abbreviate anything! BW_RCB01_SW meant something to the team who did our CSS to years ago, but it doesn't mean anything to me now and I have to work backwards to try to translate what BW_RCB01_SW corresponds to for my purposes, and either remember that translation or document it somewhere. Better? blackwhite-boxtype1-bottomleft. It's longer but also doesn't require a Rosetta stone.

• Keep it all lower-case and use underscores or hyphens. I prefer hyphens, but that's totally a preference. There should be no impediment to using hyphens, since they are not reserved in CSS or HTML and IDs are treated as literal strings in every other language. Lower case is all experience - too many hours wasted wondering why the heck won't this style apply oh. pageContainerLeft is not the same as pageContainerleft.

• Identify exactly what that element is, but no more. Think seriously about each piece of information you're embedding in the name and whether it's necessary. In your example - do you need to know it's a checkbox by the ID? Unlikely. You already know what element you're referring to because it's a unique ID and you have to code against that element anyway.

Answer 4

Naming as few objects as possible definitely helps keep things clean. If you can get by naming the parent and just referring to the child, that's going to be better (in my opinion). You get the bonus of slightly less html rendered to the client on each page.

For when I do have to name elements though, I prefer all lowercase, with underscore notation. I've been tricked up by not getting my case right in CSS files before, so if I can count that out as a problem early, that's as relief.

Underscores are characters while dashes can be interpreted as minus's, so that's one more potential problem - makes sense to stick with underscores only. Flex, for instance, doesn't accept XML with attributes named with dashes (i know these are values not attributes; but still a safe bet).

I agree with above though -- no element types or positioning or color as a class/id. Hungarian notation == bad. Very useful to determine what's an ID. I like naming form fields in a object specific ways - user_login, user_email, user_address_state_id, user_address_country_id etc, might all show up on a user registration form. Usually non-form fields aren't long enough for underscores, otherwise you might be able to rename them.

Answer 5

Believe it or not, but I've had problems with hyphens as names of id's and css class names when using certain javascript libraries. This is very rare, but you obviously want to avoid something like this. Because of this I use camel case or underscores. You can use underscores as well.

Otherwise the general rule is to have meaningful names that are easily read and understood. When it comes to "controls" make sure you follow some sort of a naming convention. Personally i prefer postfixes over prefixes (i.e. nameText instead of textName) but I try to avoid postfixes as I find them too verbose.

So: 1. Meaningful names. 2. Avoid post-/prefix. 3. Avoid abbreviations (ie. address instead of addr). 4. Take your time.