multiple classes on single element html [closed] - html

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is it a good practice to use many classes on one single HTML element? For example:
<div class="nav nav-centered nav-reversed navbar navigation-block"></div>
I don't mean that two or three classes on one element is bad, but how about four, five or even six?

Short Answer
Yes.
Explanation
It is a good practice since an element can be a part of different groups, and you may want specific elements to be a part of more than one group. The element can hold an infinite number of classes in HTML5, while in HTML4 you are limited by a specific length.
The following example will show you the use of multiple classes.
The first class makes the text color red.
The second class makes the background-color blue.
See how the DOM Element with multiple classes will behave, it will wear both CSS statements at the same time.
Result: multiple CSS statements in different classes will stack up.
You can read more about CSS Specificity.
CSS
.class1 {
color:red;
}
.class2 {
background-color:blue;
}
HTML
<div class="class1">text 1</div>
<div class="class2">text 2</div>
<div class="class1 class2">text 3</div>
Live demo

It's a good practice if you need them. It's also a good practice is they make sense, so future coders can understand what you're doing.
But generally, no it's not a good practice to attach 10 class names to an object because most likely whatever you're using them for, you could accomplish the same thing with far fewer classes. Probably just 1 or 2.
To qualify that statement, javascript plugins and scripts may append far more classnames to do whatever it is they're going to do. Modernizr for example appends anywhere from 5 - 25 classes to your body tag, and there's a very good reason for it. jQuery UI appends lots of classnames when you use one of the widgets in that library.

Related

Recommended CSS style Guide [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Let we have a html like this;
<div class="mainElement">
<div class="subElement1">...</div>
<div class="subElement2">...</div>
<div class="subElement3">...</div>
</div>
So if want to style that 'subElement1' which one is more standart or faster.
.mainElement > .subElement1{
/*some CSS here..*/
}
.mainElement .subElement1{
/*some CSS here..*/
}
.mainElement > div:first-child{
/*some CSS here..*/
}
From ones you have, best is:
.mainElement > .subElement1{
/*some CSS here..*/
}
because it targets direct child from parent class.
But if you really want performance, you want to target class directly:
.subElement1{
/*some CSS here..*/
}
Or if you want even more faster code, use IDs:
#subElement1{
/*some CSS here..*/
}
IDs are generally faster for browser to target, since they are supposed to be used only once per element.
Browsers read CSS from right to left, so adding a parent class/id unless you really need it, is only slowing down your code.
Why not just .subelement1?
If there is no reason to nest your selectors it is better off not to nest/couple them together.
But for your question it really depends on what you are trying to do the options you have posted all do different things.
The first one is fast and specific but selects only direct descendants of .mainElement
The second option selects all .subelement1 classes that are within .mainElement which right now is only one element but you can keep nesting them inside of each other and they would all get the same styling not just the direct descendants.
As for the last one it is the most specific and could get you into trouble it finds the a div inside of .mainElement that is a first-child this could lead to trouble if you were to change the markup at all and say uses spans instead of divs also only the first child will always get that styling no matter what class you gave it.
.subElement is enough, you shouldn't access the parent class first, cause it's affect to file size (althaough very small size) and make the css load file slower. Hope this link help you Writing efficient CSS

When a specific css style is very often used, should it be a own class? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
When I need very often a specific style like float: left is it better to make a own class or put this style in every class where it is needed?
Here is a example page for what I mean.
JS-Fiddle Example
Is it good how the class left is used? Or would it be better when I put every float: left style into the other classes?
The things to consider are readability and repeating yourself.
Readability:
Having a left class with the only rule as float: left will help to make your HTML more readable. Because whenever someone see that class on an element, they know it will be floated left. So in that way it improves readability.
DRY:
With CSS the old adage of "don't repeat yourself" is almost impossible to adhere to, but I think it should still be considered. In this case you should compare.
How many times will I add float: left in my CSS? versus How many times will I add class='left' in my HTML?
I would note that most CSS frameworks use utility classes like .left{float:left;}
It's simply a matter of opinion but I'd argue that no, you shouldn't.
HTML and CSS exist separately because they address separate concerns. HTML represents the information and CSS represents how that data should be displayed.
Creating classes containing only one rule starts to blur that distinction and starts to introduce style-specific information into your HTML.
Say you want to change all your stuff that was floated left to be floated right. You could either change your CSS rule to something like
.left {
float: right;
}
which is obviously horrendous or else you'd have to go into your HTML and change the class in every situation you wanted to change the value of the float - not ideal either. In a perfect world, you want to be able to make styling changes ONLY by editing the CSS. That's what it's there for. Obviously sometimes this just isn't possible but a lot of the time it is if you marked up your HTML in a semantically meaningful way.
There isn't anything wrong with doing that.
I create css helper classes for myself all the time.
When you're not using a framework like bootstrap it really helps to be able to add class="border" your html to quickly see what's going on in the box model
There are many opinions on top of this,
depends on your context...
In Sass there are placeholder selectors, you should have a look on how they work
Other way is creating helper classes, an example could be the pull-left implemented in bootstrap...
A simple class that does just one thing in order to be reusable everywhere in your code...
The first solution increases the output css file, the second, instead, increases the html file...
Maybe the secondone could be better that the first.

CSS class naming - context in name or not? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've got (hopefully) quite interesting questions, regarding code semantics. Should a class name be specific in it's role even in a bigger context? I'll just give an example:
I need a class for description container. But on the page, description exists in various places: .page-slider, .offers, .articles etc.
So there are 2 options: either name class .description, and style each one individually in contex of it's parent (for example .page-slider .description). Another way is to make it self-explainable, like .offer-description, .slide-description etc.
The pros of first option are short names and imposing keeping the code inherit depenend (the question is if it's stil the right way, SASS kinda encouraged me to limit the selectors inheritance)
The pros of self-explainable names could be their movability, better explained, if called directly throught jQuery, and minimizing the css nesting. The con is possibly long names in the future (bloat + additional parsing time for browser).
Thanks in advance!
The main factors to choose which method I would use would depend on answering these two questions:
Do I understand what the selector selects?
In your example ".slide-description" and ".page-slider .description" both explain what the selectors select. I personally am in favor of using ".page-slider .description" because it would say to me "I am a description of my parent item page-slider". Using ".slide-description" I would not understand that it is about a description of ".page-slider" without having to read the html (Maybe I would if you called it ".page-slider-description", but it still won't tell me it is a description of its parent-item).
Will my selector allow me to make changes easily in the future?
At some point you might decide to change some things on your website. Having to change every description will get boring fast. Instead you would be better off using ".description" to change some general styles of your ".description" divs. Since they all have the same function on the site they probably share a lot of properties. You can always override the ones you want using ".page-slider .description". Once again I seem to be in favor of the ".page-slider .description" -method.
mmmm I would consider the visual design (if you have one) to see if the description class had common styles throughout its use in .slider, .offer and .articles If it did I would use .description and apply all the common styles. Then add additional styles based on the parent.
You could literally call your description container class .description-cont or .description-container.
If I was writing it in SASS I wouldnt make it self-explainable. I would simply have:
.slider{
//styles
.description{
//styles
}
}
Thanks

Should we give id's to <hr> <br> etc? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Just had a discussion on some html concepts and the question arises should we give id's to hr and br tags. Both do not contain/handle the content in any way and both have fixed functionality. So invoking the DOM on basis of id's is a good coding practice or not?
Take scenario suppose I want to apply css to a hr tag. One option is giving hr an id/class like
<hr id="hrIdName"></hr>
and use css like
#hrIdName
{
}
Other is enclose hr in div and then use selector to implement the css
<div id="hrIdName">
<hr>
</div>
and use CSS like
#hrIdName hr
{
}
Out of two which is a better approach and meets good coding practice?
I wouldn't do either. I have been working a lot recently with jQuery Mobile and the interesting thing about that is they assign classes based on the CSS function you want.
So for example, if you wanted a HR to have margin and padding, you could use:
<hr class="margin-padding">
It would be better this way because you could re-use your classes on the same page (as you would likely want to with a hr). Also you cant repeat id's.
EDIT
Or as peopel have aid on your comments, dont use them at all because div and span elements should be used.

What is better css selector practice: Using multiple element or using one id/class? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What is better using Alt A header nav ul li a {color: red} or Alt B .nav-link {color:red}?
The pros for Alt a is that i don't need to introduce any more css id/classes, but it is more prone to specificity war than alt B.
Check out jsfiddle: http://jsfiddle.net/43znf/1/
This really is subjective. When I first learned I did everything using Alt A, but now I do a mix of A and B. Alt A will apply the style to every <header> <nav> <ul> <li> <a> nested element, meaning that if you have multiple sections that match this nest pattern they will be styled in the designated way. When you use Alt B, you have to apply the class / id to a certain element, meaning that you can pick and choose which nested <a> tag will receive the style.
Bottom line, it really is not practical to just code in Alt A or Alt B. I would recommend using a little of each.
EDIT: If you plan on getting a job where HTML / CSS editing is required, your boss may have a certain way he or she wants it done. Just some heads up.
EDIT 2: It's also a good idea to know when it's the appropriate time to use an ID and when a Class should be used. ID's should only be used once in a document, classes can be used multiple times.
It depends on how versatile you want your CSS to be. If you have a single element that you want styled or just a handful, use the id or class. However, using Alt A will allow you to add new elements without necessarily having to assign the id/class.
You could use both and both have valid use cases in real life.
When you have an element that is unique and sure that its styles need not be used anywhere else you could make use of id for simplicity.
eg: Header section of your website "template" or "layout" which remains same and probably you would not reuse the styles.
But when you have to style an element say a form button, you have to use a css class, as the form button will be used many a times as you would see.
Using classes can be elegant in that if you stick to the principles. Do not overstyle an element using a single class. Split the rules in an intelligent manner so that each class can be used somewhere else. Try to avoid writing context specific rules in a class which will block you from inheriting the class.