This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
CSS Best Practice about ID and Class?
To me, it seems like both achieve the same thing. So are there any rules or standards as to when ids are more appropriate over classes and vice versa.
I know this question may be seen as subjective, I don't have any preference over one or the other and am not trying to peddle anything here. I am genuinely curious as I am new to front end web development and would like to know which to use and when.
CSS Best Practice about ID and Class?
When you need give multiple things an attribute/style, use a class, if it's singular, use an ID. If it's something I want to readily identify, like LoginBtn then it's an ID, if it's a style, like say an anchor that's blueLink, it's a class.
Another consideration for a lot of developers is javascript. e.g. a jQuery selector $('#id') is much faster than $('.class'), so if you're only dealing with one element, this is also an advantage.
This is not subjective. Classes can be used to give the two separate entities in the html (such as two divs) the same styling. Id's are unique and therefore can only style 1 element at a time.
edit: clarification
Related
The names behind PrimeFaces' class attribute values in the html generated for data grids -- like ui-paginator-rpp-options for the rows per page display/input, and ui-paginator for the page "navigator" GUI component -- are those names PrimeFaces-specific? Or could I easily find other UIs that use the same names in the class attribute?
My understanding is those names have been created by PrimeFaces, and there was no other pseudo-standard using those names earlier, right?
I am simply wondering if the code I am writing to address GUI details like these is PrimeFaces-specific or not, which would have consequences for the architecture I am designing for a test framework. It should clearly reflect what refers to (and conceptually depends on) what ;)
I am amazed that after years of wrangling with this stuff, I still am note sure about this. If the answer is so obvious that it embarrasses me too much, I will delete this question (I think :) )
Many classes in PrimeFaces come from the jquery-ui guidelines. But indeed some are PF specific. If styling in PrimeFaces needed to be done for components or component parts that have no counterpart in the jquery-ui set of components, they 'invented' new classes. It would indeed have been better if those would not have gotten the ui- prefix, but a pf- prefix.
There is, afaik, not en exaustive list or even a non-exhaustive one that contains an overview of all of these
I'm coding a landing page. When should I use an ID for an element instead of a class? I know IDs are only referred to once on a page, while classes are referred to multiple times. I also know using a class is faster than using an ID. When should we use a class over and ID for an element?
Simply put, ID's are for JavaScript, classes are for styling (CSS). You can use Id's for styling still however, where needed. But in general, you should work towards using CSS classes and re-usable code.
Some people also follow a convention of using ID's for chrome elements on their site. Myself, I use classes for everything to allow for future code re-usability. I can't tell you how many times this has made life easier 6 months down the track. If I need to target something with JavaScript, then I also add an ID.
Performance
JavaScript
Id's are faster than classes when referenced in JavaScript.
CSS
Performance depends on the individual browser rendering engine.
Best Practice
Check out this handy guide on MDN that teaches you to write efficient CSS.
This question already has answers here:
Best way to structure a CSS stylesheet [closed]
(2 answers)
Closed 8 years ago.
I am creating a design for a mid-sized Web application. It's my first time, and there is no established design process at my workplace. Previous projects are small internal applications, and the back-end developer used a minimal design just enough to make stuff align where it should.
I started doing the design for each type of page separately, and created a new CSS file for each type of page, e.g. a separate one for input forms, another one for the search interface, and so on. I also made one large file with elements used everywhere (header, footer, buttons, warning messages and so on). It was the only reasonable structure I could think of.
I've been at it for a while, and I'm now noticing that I've created some sort of chaos. When I have an element and need to change the definition of its style, I always have to go through Inspect Element and then Visual Studio's search function, which is still reasonably efficient. But I also frequently find myself looking at definitions in the stylesheet, having no idea what they are for, or if they're still in use at all - maybe we have already thrown out the elements which use them, or they were an attempt to solve a problem which got a better solution.
I am already trying to give good, semantic names to my classes, but it's not sufficient, and sometimes even impossible - every workaround I use seems to leave me with names like .centeringWrapper.
What is a good, workable structure of CSS code which prevents these problems? What principles can I apply to arranging the code?
How can I divide the code into files so I can find the correct file?
How to structure code inside the files so I can keep my orientation within a file?
How to keep the overview of different definitions for the same element which are used within different #media blocks?
Any advice for making my work less messy is welcome.
The best practice for structuring your CSS is to structure your CSS. By that I mean have a system. It doesn't really matter what your system is, as long as it makes sense to you and your team and people can consistently maintain it (at least for a reasonable length of time).
I can tell you one way not to do it, though and that's by not designing each page separately with its own CSS.
I think you've figured this out already, but it's worth repeating.
Now, there are times when I've broken this rule. But it's rare and it's typically on small marketing-centric sites where I simply have 4 very different pages. In general, though, you want to re-use as much of your CSS as you can across all your pages.
One way to achieve that is to start with a pre-existing structure by working off of a CSS framework. A common one is Bootstrap, but there are literally dozens and dozens of options out there.
I've read this
Why selecting by ID is not recommended in CSS?
which presents arguments for why you would use classes instead of ID's. And many dev's go cold turkey and refuse to use ID's at all for style selectors.
But, I'm sure many if not most experienced devs still use ID's as stylistic hooks(while favoring classes).
What are some possible scenarios that might justify using ID's instead of classes?
You may use ids when you are targeting unique items (you don't want to reuse that particular style) like #header,#footer.
Another good reason to use ids may be if you're a front-end developer thattakes care of some basic javascript too. Javascript access to elements via id is a lot faster than by other chained class names, so for performance reasons , you (as a js developer) might want add an id to your widget that allows you to access that element a lot faster.
For example
#widget
is faster and easier to access through js than something like
.wrapper .container .sidebar .widget:nth-child(n)
From what I've found, people (not all, but most) that try to only use class and attribute selectors make a mess of their style sheets. They end up putting a class on everything and then have long selector strings trying to move one certain element, which is where ID selectors shine. ID's were implemented into CSS for a reason and they are great when used properly.
Just use sparingly.
I was reading this:
"Guideline Number 7: Try to avoid using unecessary classes and IDs.
So, now that we’re keeping our hooks to a minimum, it’s time for our next step in quality over quantity: naming. We want to avoid names that imply presentational aspects. Otherwise, if we name something right-col, it’s entirely possible that the CSS would change and our “right-col” would end up actually being displayed on the left side of our page. That could lead to some confusion in the future, so it’s best that we avoid these types of presentational naming schemes."
So what do I call them if not right-col and not presentational?!?!
I discuss this very topic in "How to Develop with CSS". What you call it depends on the content. Maybe "sidebar" or "links" or "extra".
any naming technique has advantages and disadvantages...try to find a way that help you more in your work, and make well commented css files.
Rather than naming things after their presentation name them for their function, or purpose. Also, try to use a coherent page structure so far as possible, and use the CSS cascade to access/target elements.
As long as it conveys meaning for the html structure and other developers can understand well it should be fine.
check out 960.gs using that gridsystem will save a lot of time, trying to figure out the best naming scheme.
NCSS Sheets is a naming convention and guideline for semantic CSS: CSS class naming convention