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

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

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.

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

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.