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 am wondering, which way is real objective oriented CSS where you can reuse components really quickly in a clean way.
Scenario 1:
HTML:
<button class="button button-submit">Submit</button>
CSS:
.button {
/* basic styles */
}
.button-submit {
/* special styles for submit button */
}
Scenario 2:
HTML
<button class="button submit">Submit</button>
CSS
.button {
/* basic styles */
}
.button.submit {
/* special styles */
}
I only see two negative aspects, one in each scenario.
In scenario 1 you might end up having really long class names.
In scenario 2, if you define .submit as it's own element/component, you end up with the old problem where you cannot reuse code fragments to stay the same in any place.
Scenario 1 would probably be the more OO one but like all technologies and methodologies I would use the one that suits your needs best and you are going to enjoy writing.
Currently I am rebuilding an ecommerce platform from the ground up and when researching wanted to adopt similar methods. I ended up ignoring ways similar to your first example due to the long class names like you mentioned.
The idea behind all of it is to make writing code easier, quicker and more reusable. As soon as one of those factors is impacted too much while trying to satisfy the other, the whole idea behind trying them in the first place is voided.
Just to note this is a purely subjective answer and everyone is different.
Some good articles on the various methodologies and practices that I used to help make a decision:
http://www.smashingmagazine.com/2012/04/16/a-new-front-end-methodology-bem/
http://webuild.envato.com/blog/how-to-scale-and-maintain-legacy-css-with-sass-and-smacss/
https://smacss.com/book/
http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/
Hope this helps!
CSS is not OOP, you can however, use frameworks which allow to you code CSS in a DRY manner.
SASS
LESS
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I see the trend of css utils class and I am wondering if there is an impact on performance for this style.
What will be a better way?
One - make your html element with bunch of utils classes like:
<div class="padding flex justifyCenter alignCenter textRight"></div>
Two - make your css ( with preprocessor like sass ) like this:
%flex {
// code
}
%textRight {
// code
}
div {
#extend %flex;
#extend %textRight;
}
h1 {
#extend %flex;
#extend %textRight;
}
Will output:
div, h1 {
// with flex and text right
}
Utility Classes will almost always be the optimal solution based off of the two examples you've provided.
The corresponding styles for the utility class tend to be quite small and the reference from HTML promotes reuse of these definitions. From a performance perspective they will have negligible impact since complex algorithms implemented in browsers and hashing allow them to reference rules and apply styles extremely quickly.
Using #extend or an equivalent can lead to huge files when generated from e.g. SASS since the selectors for the rules become massive with many clauses.
It is generally bad practice to use #extend a lot when creating styles as mixins are typically favourable.
If you've ever opened developer tools on a site with CSS where e.g. the grid elements all comprise of extended selectors then the performance is horrible as the browser tries to manage the selectors.
I'm not saying not to use extend but it should be used sparingly.
If you are in a situation where you need to use these utility classes often and have a preprocessor at your disposal you might be best making flex and textRight mixins and just #include them where you want those corresponding styles. This will give you the optimal CSS output since a preprocessor can condense the rules and prevent repetition.
If you are not using a preprocessor you're also fine using the defined utility classes in your HTML. It still beats inline css to apply a small rule e.g. text-align.
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.
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
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
I'm working on a responsive theme that I want to sell. I really want to make it easy to understand at a glance what's going on. One of the tradeoffs of moving from foundation 3 to bootstrap 3 and Foundation 4 (in my opinion, and as noted elsewhere), is the nearer - verbose naming you have to adopt when designing for multpile screen sizes.
Thus, I've tried as much as possible to achieve something like this:
<a class="button soluks_button square_round no_bold">Button</a>
OR This
<a class="custom-button green square-round button-in-navbar text-shadow">Button</a>
Given I'm building my styles on top of bootstrap and foundation, is this too much? or is it okay as long as its readable?
You should make use of a CSS preprocess such as SASS or LESS to keep the HTML semantic and significantly easier for your end-users to work with.
Using the SASS directive #extend, you could give class names as you are currently doing, but extend them in the css rather than forcing the user to remember to include each one in the html. However, by using #extend, the classes could still be applied individually if needed/ if the user wanted to change the default. Something like this:
.button {
display: inline-block;
}
.square-round {
#extend .button;
border-radius: 5px;
}
.no-bold {
font-weight: normal;
}
.soluks_button {
#extend .square-round; // which extends .button by inheritance
background: blue;
}
Then your html could be much more semantic and just give the class of the actual element itself:
<a class="soluks_button no-bold">button</a>
And for the purpose of a versatile theme, to change the default or add an additional style a user could still do:
button
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.