With the rise of styling libraries and mixed CSS in JS solutions, I've seen increased use of classes, while ID selectors are nearly extinct.
Even when understanding the code structure/context and noticing that the element is clearly unique and used once throughout the whole app, it's often still given a class to access via CSS.
Do you still use ID attributes for unique elements?
Top comments (29)
You can't avoid id in this case:
(yes I know that id isn't needed if input is inside label, but this may not be feasible if there are other elements in between)
Can you use
name? - w3schools.com/TAGS/att_input_name.aspNo, the for attribute cross-references only to the id attribute. This is most important for radio buttons and check-boxes where multiple input elements share a common name to belong to the same group but each needs to be labelled differently.
Classes should identify, well, classes while unique elements should be identified by IDs. The problem is that elements can be "unique" in a certain context, like an SVG graphic, but that whole context might appear repeatedly in a document. An easy way to deal with this is to just use classes instead of IDs.
Over-use of classes seems to be a general problem with "modern CSS" though. Programmers don't want to bother understanding CSS properly so they default to sticking labels on elements, which is closer to the sort of thinking you use when writing program code.
Personally, I prefer the third alternative: Prefer describing over naming, that is, use neither class- nor id-selectors whenever possible.
So use what? just tag names and pseudo-selectors? It makes it much harder though
Did I say you shouldn't ever use class- and id-selectors?
Most CSS I see has things like
.some-wrapper-classand then.some-wrapper-class-child. My point is that you should write.come-wrapper-class>*instead, which is both more readable and more maintainable.I'm not against naming. I'm just saying if you can, you should prefer describing.
Found a nice article that confirms what you said. The best part is the conclusion:
Or, to throw a very well-known quote at the wall
We live in 2020. Browsers have magnificent benchmark tools that can help us find bottlenecks, and yes, of course we should give up good style if we can significantly improve performance. But that doesn't make it a good "default style" to start coding.
When I write some code to handle data I don't do manual CSE or Loop Fusion either, because it creates an unreadable mess. When a bit of hot code runs too slow, I then optimise it. Same with CSS, except I don't usually even write nearly enough CSS for it to start slowing down a site.
Markdown parser generates
id, so that it can used for anchors, I think. With a certain markdown-it plugin, you can make a clickable as well.Like
#unique-idmeans that you can go to fromThere are, at my last count, 11 different uses of id attributes in HTML, only one of which is their use in CSS selectors. The other 10 require the id to identify a single element within the document.
For CSS selectors, omitting using id selectors when appropriate to do so, means missing out on some of the power that specificity brings to you.
Examples please
document.getElementByIdto name a few
I think I'd has two main usecases:
-The label for attribute
yes and a few more actually
Could you elaborate?
I consider styling with CSS classes to be a best practice. Even if I am styling a unique element, I don't use ids because I want to leave my markup open to extension and can't guarantee that I will never need an element like that again.
I sometimes still do that, e.g. a logo that appears on a navbar is often unique, or the headers in section for a blog post (so that a user can link to specific parts rather than the whole document similar to what MSDN does) If you look at websites created by MS you'll notice that they also still use IDs for styling elements that are guaranteed to be unique.
Yes totally "still" using IDs.
The way this question is presented feels like we should stop using the ID attribute? Does anyone else feel that too?
Sometimes. Generally, I like
idfor 'hooking' with JS - if it's really just one thing. Case and point,Reactis using"#app".Obviously. IDs are for element identification, which means uniqueness. Classes are for, well, classes of elements. Querying the entire DOM for an element through classes when you can simply use IDs is a waste of time and resources. Just use IDs when you need to target one very specific element; otherwise, when targeting a class of elements, use classes (the names are so self-descriptive, why is it still being discussed?).
Its ironic but the more classes become popular the more ids become powerful.
Meaning if a CSS framework is based entirely on classes then overriding a style for a certain element without headache is as simple as giving it an id, since id's have priority over classes.
Yep I do 😂
Haha, I do, too 😄😄
I'm trying to avoid as much as possible, since eventually it's becomes to a variable on window...
Yeah in certain cases for sure:
document.querySelector('.myclass') is even cooler :P
It depends. When there just happens to be one top menu, class is safer. When it has to be id for some reason, id it is.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.