Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Once I needed to make an internal IE addon to listen for certain elements being selected on pages outside of our control. (to ensure we never collected sensitive data for compliance reasons, long story. Trust me it makes more sense in context than it does in a single paragraph.)

My co-worker wanted to grab by id and attach listeners, but I was convinced that wouldn't work. I wanted to listen at the top level and filter down by id/class/etc...

The first production test was <redacted>.com/login. It had a login widget on the navbar and a login widget in the main content section. Both the username and the password field had the same id in the navbar and the content. So the addon did the right thing on the navbar, but not in the content, and we had to go back and redo it thanks to id reuse.

My point is, elements with ids are rarely unique. I've never regretted using a class instead of an id. I've regretted using an id instead of a class. And I really regretted third parties using ids instead of classes.

Please don't use ids. Your unique elements won't be for long, I guarantee it.



A friend once told me about a girl in their cs 101 class, who learned about arrays, and proceeded to make every variable an array. When queried, she responded, "I might end up realizing I need a multiple of the variable, and this way I won't have to change anything when I do".


Did she then go on to create jQuery? Because that concept (with a touch of functional inspiration) is one of the underlying ideas behind the library and why it was considered so much easier to work with than the DOM API.

I get where you're coming from, but I don't think it's a good reason to avoid classes. That's what they're there for.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: