As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Say I have a color I know I am going to use a lot of in a website.
I could either define the colour lots of times in various CSS class's
.nav-login { color:#green; other CSS content....... }
Or
.green {color:green;}
.nav-login { other CSS content....... }
<div class="nav-login green">stuff</div>
So the concept is, should you use helper CSS classes or should you define everything specific?
Theoretically, you will save bandwidth in the long term by writing more CSS and less HTML, yet I find the method of applying helper CSS classes in the HTML pleasing, almost as if you are writing semantic CSS in a design sense.
I personally don't think it's a good idea to name classes based on their properties, like .green for a green-colored text. Instead, use a qualifier, say .approved for green text, and .warning for warnings, alerts and etc.
In my humble opinion, the selectors (classes, IDs) should reflect the role/purpose of the element, and not their appearance. Say for example, if you want to redesign your site and adopt a new colour scheme, and your navigation menu changes from green to blue - then, the .green selector will have very little meaning, and will be hard to understand to whoever is taking over the project in the future, if any.
Moreover, there is no reason to assign a .green class to the navigation login <div>, if you can already specify it using .nav-login.
Chris Coyier has compiled a rather comprehensive CSS style guide - it's not the golden rule, but it's good to follow.
Have a look at OOCSS (and Smashing Mag introduction to it)) if you didn't already have. Also to BEM from Yandex - again Smashing Mag intro to it.
I'd have laughed at the idea of not strictly separating content (HTML) from style (CSS) a few years ago, I scratched my head when Nicole "stubbornella" Sullivan gave a talk about it in a conference I attended but now that I'm working on projects made of dozens of pages to where we have to go from PSD to HTML/CSS for a client inside a team of a few people, my requirements have drastically changed!
Working alone on CSS that nobody else will modify or in a team on a single project in a startup or in a team for a client that'll reuse the CSS you create aren't the same at all.
Learn about OOCSS and what it can do for you, give it a try and don't use it in your projects if it isn't suitable. Or do.
Using CSS preprocessors or not is quite irrelevant here: if you use them to output 1 kilometer long selectors, you're using them wrong obviously. They're just a way to write CSS faster and with less pain (not having to bother to learn which prefix are needed for each CSS3 property thanks to macros is great, but they should still output more or less the same CSS than before). The point is to write efficient CSS, with or without a preprocessor. Same with ZenCoding/Emmet: you know you need it when you're fed up with writing the same repeated lines/instructions day after day. But they'll output these same lines of CSS, nothing magical here.
Actually, it is a good idea. I use them too, but I do not name them the way you said. teddyrised' example is good.
Just my example, when I make a simple project that does not need a huge page structure and minimal CSS, I name them like this:
.push-right {
float: right;
}
push-left {
float: left;
}
.no-float {
float: none;
}
.centered {
margin: 0 auto;
}
.success {
color: green;
}
.error {
color: red;
}
.warning {
color: orange;
}
.info {
color: blue;
}
So actually it is okay to use them. Just watch out for naming them :)
I'm going to offer a completely different solution to your problem. Use Less.
Using this, you will be able to define variables and a lot of other cool stuff too.
Variables allow you to specify widely used values in a single place, and then re-use them throughout the style sheet, making global changes as easy as changing one line of code.
Related
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
For example:
class="profile profile-image profile-image-large"
OR
class="profile profile-image profile-image-small"
Is there something wrong with these names or dashes?
A good rule of thumb when naming classes is to describe the purpose of the element's content.
PREFERRED
<div class="copyright"></div>
OR
<div class="social-media-buttons"></div>
In contrast, for reasons described below, being overly precise should be avoided.
LESS BENEFICIAL
<div class="column-1"></div>
OR
<div class="right-bottom"></div>
Here are some guidelines from the W3C:
Use class with semantics in mind.
Often people use class names like bluetext, or redborder. A much
better way to name your classes is with the role a certain HTML
element of that class has.
Good names don't change
Think about why you want something to look a certain way, and not
really about how it should look. Looks can always change, but the
reasons for giving something a look stay the same.
Good names
warning, important, downloadableImage and submenu are all
good names. They describe what a certain element represents, and they
are not likely to change. A warning will always remain a warning, no
matter how much the look of the page changes.
Bad names
border4px, lighttext and prettybackground are examples of bad names. You
might fatten that border to a whopping 5 pixels, or the background may look
pretty old after a while, and not pretty at all. An advantage of using
CSS is that you won't have to change much in order to change the looks
of your website. If you have to change all light text into dark text,
and thus change all classes lighttext to darktext in all your HTML
pages, you're likely to miss a few.
So, to answer the question:
Is there something wrong with this?
class="profile profile-image profile-image-large"
class="profile profile-image profile-image-small"
Well, do these class names represent "the role [the] HTML element of that class has"?
It's mixed. profile and profile-image are clear roles. But large and small simply represent how the image should look, which, as the W3C points out, can change. And if the size changes then the class name may have to change, as well.
Which leads me to this: The important issue isn't really the prefixing, suffixing or hyphenation of class names. What really matters is the quality of the name itself.
Maybe this would align with the W3C guidelines and offer greater benefits in terms of reusability, flexibility, and maintenance.
class="profile profile-image profile-image-main"
class="profile profile-image profile-image-thumbnail"
To be perfectly honest, this comes down to individual developers and their own feelings. There are two equally good ways of structuring CSS classes, just like you suggested:
.profile.image.large{
width: 300px;
}
/* Or: */
.profile-image-large{
width:300px;
}
They achieve the same thing, but when you start thinking broadly, you see just how wide the gap between these styles becomes.
Separating classes makes them re-usable: The DRY convention is to never repeat yourself. By separating the large or image classes, we can reuse the same class:
.blue{
border: 3px solid blue; /* All .blue's will have a blue border */
}
.profile.blue{
border-style: dashed; /* Inherits from the previous blue and replaces the solid with a dash. */
}
In the second approach - using - separators, the code would be:
.blue{
border: 3px solid blue; /* All .blue's will have a blue border */
}
.profile-blue{
border: 3px dashed blue; /* We had to redefine the entire style */
}
On a simple example like a border, this doesn't seem to matter. But take into account a much larger CSS chunk that you may want to re-use dozens of times throughout your code. You'll be repeating yourself a lot.
Logically grouping styles is still a good thing: I'm not saying that -classes are a bad thing - they help define a namespace for your code, so in the sense of maintaining modular code, prefixing your styles with an identifier will help prevent conflicts, especially if you're developing code inside a web agency that will be re-used, or if you're building a plugin (in which case, style prefixing is absolutely needed).
Developing in a compiled language like SCSS (my preferred environment) changes how you think too. In SASS/SCSS we can easily do this:
.profile{
display: block;
&-image{
border: 1px solid blue;
}
}
And that evaluates to the same as profile profile-image on the element. Alternatively SASS also supports:
.profile{
display: block;
&.image{
border: 1px solid blue;
}
}
Which evaluates to profile image on an element. Very similar - but both styles are restricted to their parent element .profile and can't be used globally. The styles are protected, whereas in my first 'natural' CSS example, the blue class could freely be added and incorporated by any element in the HTML page.
Edit: You could still use a global .image style in your SASS code, and then override individual examples, but personally, I feel this violates the DRY principle and I try to avoid doing it where possible.
So what's the TL;DR?
In my opinion, there's no "right answer". From a conventions standpoint, it's worth noting that frameworks like Twitter-Boostrap use a hybrid of the two styles - global classes that can be applied everywhere, mixed with prefixed classes that protect their children's styles.
The most important thing for any programmer is that your code is clearly readable and defined, and that you use as little code as possible to achieve your result - no matter what method you use.
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
It seems there are two major schools of thought on how to structure CSS and HTML. I was taught to keep the HTML as clean as possible, and all things stylistic should be on the stylesheet. This has served me well thus far, but with this approach I often notice redundancies and inefficiencies.
I read up on the atomic approach, and I really like the idea. It seems to be the method I naturally gravitate toward anyway.
My question:
Which way is really faster, considering the two following blocks of code:
HTML:
<div class="main">
<h1 class="m-10 theme-c1">header with margin and theme color 1</h1>
<p class="fz-1 theme-c1 m-10">paragraph with font-size 1em.</p>
<div class="m-10">
<p class="fz-1 m-10">blah</p>
<p class="sub-paragraph">Sub paragraph</p>
</div>
</div>
Stylesheet:
/*margin-left rule*/
.ml-10 {margin-left:
/*font-size rule*/
.fz-1 {font-size:1em}
/*theme color*/
.theme-c {color: #333};
/*display rule*/
.dps-blk {display: block}
/
/*sub paragraph styles*/
.sub-paragraph {
margin-left: 10px;
font-size: 1em;
font-color: #333;
}
Elements in the HTML above all get whatever style they need, and the styles above are non-descendants except for .sub-paragraph.
So is it faster for each element to cherry pick which styles it needs, or is it better to just give it a chunk of styles (like for .sub-paragraph)? With .sub-paragraph, I can see how it only takes one match to get all the styles. The trade off, however, is that there isn't much else you can do with that set of styles except use it on sub-paragraph, or override some of its properties with another rule when applied to something else.
I'm think with these two approaches, it's a decision on whether to the cost on data size or on processing time.
Edit
I appreciate all the feedback. I forgot to mention that I'm specifically interested in the processing speeds of the different approaches.
This is interesting nonetheless.
If you were to begin cherry picking individual styles, you would end up with a stylesheet like:
.red{ color: red; }
.green-background{ background: green; }
.w500{ width: 500; }
.ml20{ margin-left:20px; }
Which is not very maintainable.
It sounds like what you are looking for is a way to extend certain classes (i.e. .sub-paragraph) with pre-existing classes, adding the styles of other classes into .sub-paragraph. SASS's .extend directive is a great way of doing this.
Sass and other preprocessors are great at merging the ideas of maintainable code and semantic code together.
Edit 1:
If you are looking into which method (more classes/less properties or less classes/more properties) is faster, I would suggest doing some testing with Chrome Dev Tools' Timeline. The two methods of coding aren't the only thing that are going to affect how fast a page renders/paints, so it is always a good idea to test these if you are concerned about speed.
I organize my CSS by grouping certain types of classes together. When creating CSS classes I ask myself, am I going to reuse this class definition for anything else? Is it logical for me to separate this class' definition, will someone who has to read this after me want to shoot themselves?
Basically I would say, go for maintainability, an extra 1Kb on your Css will not choke anyone.
CSS is designed to use classes for certain groups of styles. The .sub-paragraph method is usually way better than the seperate classes method. If you are going to assign classes for each style seperately, you might as well just use inline styles, via the style attribute. You should usually try to avoid that for maintenance reasons though.
I think there is a place for both.
I don't feel that the abstraction belongs at class names like .p1-gr-brdr, though.
If you're writing very tightly-composed, atomic HTML partial-templates (for things like AngularJS directives), then you'd likely get more mileage out of .title, .subtitle, .just, .content, where you can specify very specific output for those components.
Changing those components will be very simple and straightforward, as they're so compact and self-contained.
And if you find yourself in a position where you need to override one, to compose an inherited class, then you either have the option of composing a new class-name, which now might not be 100% semantic/generic (".big-green-subtitle"), but is still 100% self-contained for those moments where you want your special-cases to feel loved, too...
...or you can then specify behavior with a second-level selector.
If your .header has a padding, but you don't want your .update > .header > .subtitle to be subject to that padding-bottom, on mobile-phones, in landscape orientation, on Tuesdays, then you can simply have an exception which states .update > .header { padding-bottom : 0; }.
Otherwise the cascade will continue as normal, and things will either pile on top of one another, or you will cancel out side-effects with specialized classes which cover the same properties...
Otherwise, I don't see why all CSS sheets don't look like:
.p1-br { border-width : 1px; }
.p2-br { border-width : 2px; }
.p3-br { border-width : 3px; }
.p4-br { border-width : 4px; }
.gr-br { border-color : green; }
.lgtgr-br { border-color : lightgreen; }
.sfmgr-br { border-color : seafoamgreen; }
.aqmr-br { border-color : aquamarine; }
.em1-wd { width : 1em; }
.em2-wd { width : 2em; }
.em3-wd { width : 3em; }
.rm1-wd { width : 1rem; }
.pc1-wd { width : 1%; }
...et cetera, until you've written out every atomic option you could possibly want, for any theme your project (and all of its components) might want to support, across all platforms.
That seems like a terrible use of your day, to write a unique class-name for every possible edge-case out there:
<div class="pos-rel
p1-br
p18-ng-tp
mrpc12-br-r
lggr-bg
bg-im-spr-id-123
pc15-bg-im-algn-lf
ofl-x-hd
ofl-y-aut
brd-bx">
Seems hefty for a single div, for instance.
This would not, however, be a bad idea, if you could write CSS rules, give them to classes, where you expect flexibility, and later had the hard-numbers to those rules.
Such that, say, you write out a class which expects to treat height in rems, margins in percents, border-radius in ems, will take a background-colour and an image-sprite (say it's a backdrop container for a corporate/retail site, with a watermark and logo, where other content will scroll above it).
Now you want to reuse that set of classes on the same component, but for a different client...
It would help if you could simply have some variables, which could live in a separate file, and be referenced by your classes, so that your units don't necessarily need to change, but you can modify all of your hard-coding stuff in one or two places, and swap different variable values in for different clients as easily as pointing at a different sheet...
...but that's what SASS already does, if you take the time to sit down and figure out how you want to engineer something, and make your build process adhere to that desired outcome.
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 9 years ago.
Improve this question
For reference:
SCSS .extend()
Similar post on this question:
Using extend for clearfix
Say I was to make a handful of classes that I could extend and reuse throughout a project:
For example a class could be:
//common boilerplate for most of my parent divs
.scaffold
{
position: relative;
-moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box;
height: 100%;
width: 100%;
margin: 0;
padding: 0;
}
//or a typical clearfix
.group:after {
content: "";
display: table;
clear: both;
}
Say I had a dozen of these classes with various purposes and/or differences within the attributes. At what point does extending the class become hurtful towards performance vs helpful? For example - if this class had say 50 commas of various classes
Example of written one of the SCSS classes
.site-header
{
#extend .group;
#extend .scaffold;
background: papayawhip;
border-bottom: 1px #ccc solid;
}
Example compiled clearfix could beCSS
.group:after, .site-header, .route-nav, .main-article, .article-header, .side-bar, .site-footer
//this could go on for a while
{
content: "";
display: table;
clear: both;
}
Example HTML
<!DOCTYPE html>
<html lang="en">
<body>
<header class="site-header">
<nav class="route-nav">
<nav>
</header>
<article class="main-article">
<header class="article-header"></header>
</article>
<aside class="side-bar">
</aside>
<footer class="site-footer">
</footer>
</body>
</html>
I feel like this could be one of the DRY—est methods to writing css. I feel like this approach could become very efficient and successful after writing just a few sections of a page. Moreover, majority of these classes could be refined and used through many project. I really want to experiment with it but I fear it could cause some performance issues in the long run, esp when classes start using pseudo-classes like :after :before.
Would there be a performance hit vs just adding the classes or writing a mixin? Does anyone have any statistics to backup the best route?
I like the idea of making scss placeholders and re-using them by #extend. This is known as the "OOSCSS" approach by some, you can find more about it if you google that. It helps writing DRY code and promotes reuse and consistency. I think you're on the right track with that idea generally, but specifically your scaffold class seems like it could be better:
.scaffold
{
position: relative;
-moz-box-sizing: border-box; -webkit-box-sizing: border-box; box-sizing: border-box;
height: 100%;
width: 100%;
margin: 0;
padding: 0;
}
Margin, padding could be set to 0 globally with a CSS reset approach, and so no need to set them each time. Box-sizing could be set with * selector, as I'm not sure you'd want to mix different box models on the same page. Making every element position relative may cause problems, I'm not sure I'd do that unless there's a good reason too. 100% width is the default anyway for block-level elements, and won't do anything for inline ones. And 100% height is rarely a satisfactory solution in my experience.
So I don't really think there's a need for that class at all. That's just an example though, the general point is if you're careful about structuring your HTML and CSS then you can get a lot of reuse from #extend without having many, many lines of commas in the generated CSS. I've found #extend'ed classes work best if they're small and specific, e.g. classes for different colors in your site color scheme, and then include them in various more specific classes as needed. It needs a bit of discipline (e.g. don't define colors anywhere else but in colors.scss, and think each time you #extend it if there's a better way), but gives very consistent and DRY code in the end.
In terms of performance, I think it's essentially a non-issue and not worth worrying about. Debugging is a bigger issue, as too much extending a single class will 'spam' the Chrome/FF CSS developer tools with huge selectors that make it more difficult to track down issues. For statistics, check out http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/
The biggest surprise is how small the delta is from the baseline to the most complex, worst performing test page. The average slowdown
across all browsers is 50 ms, and if we look at the big ones (IE 6&7,
FF3), the average delta is just 20 ms. For 70% or more of today’s
users, improving these CSS selectors would only make a 20 ms
improvement.
Optimizing your selectors gives only a 50ms performance improvement at most - and that was data from over 4 years ago, so the difference may well be less than that now. Writing CSS that's designed for maintainability, consistency and reuse is a higher priority IMO, as gains from micro-optimization of it for performance are all but unnoticeable.
The parsing of the selector has nothing to do with the performance. It's how to keep track of everything that matches. * is obvious, you have to update every element. Long queries require a lot of traversing to determine if an element matches a query. Commas? They don't matter, what matters is the content of each selector
Its not mandatory how much classes you can nest or group but I don't understand your logic behind it. Let me explain with example.
.a{
color:white;
}
.b{
font-size:10px;
}
.c{
background-color:red;
}
in HTML
<div class="a b c">TEST</div>
Why you wanna do this???
You can actually do this
.a{
color:white;
font-size:10px;
background-color:red;
}
in HTML
<div class="a">TEST</div>
Your CSS file is downloaded by the browser so if very hugh CSS style file would take more time to load, please do take it in mind. You are free to add more classes in grouping as you like but the more useless classes will be there the more slower the site will load. It will decrease your performance.
UPDATE
If you are worried about mixing classes over and over again then you should not be worried because that why we have CSS and its classes to use anywhere in the code and declared once at the top. It something like function in php, you can use function anywhere but you can use function with different arguments and hence the result will be difference.
For example in CSS,
.hidden{
display:none;
overflow:hidden;
}
.text{
font-size:10px;
color:black;
}
#id .text{
font-size:20px;
color:green;
}
So now in HTML
if we will use
<diiv id="id">
<div class="text">Text</div>
</div>
and
<div class="text">Text</div>
the results are not same.. :)
I have this base HTML/CSS template out of which I will do a lot of child websites that will use different colours and image variations for stuff like <h> tags, background color, etc etc.
I am looking for approaches to modify the base theme and make it so that in order to create child templates with color variations I will modify a single line of code (something like .this-smart-class{color: #mycolorcodehere) and voila, all the elements using that color change.
I am already cooking a method to do this myself, but I am a beginner/intermediate in front end development and I would be curious of different approaches to do this.
I am looking to use only CSS for this, maybe some jQuery but only if proves to make it a lot practical.
To better understand the question have a look at the screenshot:
variations of the same layout.
If you find this question to "unspecific" please ask me before voting down or closing it and I will break it in multiple questions, but I think good answers may come out of this, I might not use the proper terms to be as specific as I want as I am not experienced enough.
It would probably be best to use a CSS preprocessor (I prefer LESS).
You can make different color configuration files like for example "color-config-red.less" and "color-config-violet.less" where you define your different colors in variables like #background-color etc. and reuse them over the whole project. With that set up you can simply include the different color configurations for different websites while having the same layout.
I tend to use a number of generic classes which I can apply to any number of elements.
For example:
.smalltext { font-size: 0.8em }
.bold { font-weight: bold }
.clear { clear: both }
.highlight { background-color: #999999 }
I have mentioned this before and some people were critical of it but it works for me.
Then I can say:
<div id="footer" class="smalltext"></div>
<div id="box-header" class="highlight bold"></div>
I have long wanted to be able to include one style class within another. For example
med-font {
font-size:12px;
}
#message a {
style: med-font;
color: blue;
...
}
/* lots of other styles, some of which use med-font */
Obviously this is a stripped down example, but the key point is that all those anchor tags within #message shouldn't need explicit classes or ids. For now I either duplicate the font-size in each class that needs it or add classes to things that wouldn't otherwise require it. And since I want to easily control the font-size from one place, I usually start adding classes.
Another solution is to split up the definition of "#message a" in this example (below). This works ok for small projects, but for larger projects this is actually my least favoured solution. It makes site maintenance very difficult if you have many classes split apart and scattered around large style files.
med-font, #message a {
font-size:12px;
}
#message a {
color: blue;
...
}
So my question is two parts: 1. Does this annoy other people? 2. Does anyone know if this feature is/was being considered for CSS3?
Edit: Adding example of html body and more details...
The main point is that adding a class attribute to the 20 anchors below to set their font size is tedious.
<div id="username" class="med-font">schickb</div>
<div id="message">
<div id="part1">
text
<!--lots more tags and say 6 anchors -->
</div>
<div id="part2">
text
<!--lots more tags and say 8 anchors -->
</div>
</div>
<div id="footer"> <!-- footer anchors should be a smaller font-size -->
lala
<p class="med-font">Company Name</p>
<!-- other tags and 3 more anchors -->
</div>
Remember, an important goal is to have one place where "med-font" is declared so that it is easy to adjust. In my actual project, there are small, medium, and large font styles. I only want one declaration for each so that I don't have to search through the css to say change 12px to 11px.
The best solution currently is to add the "med-font" class to all the anchors in the body, and the "small-font" class to all the anchors in the footer. But I'd much rather do what I showed originally, and simply include the desired font in the styles for "#message a" and "#footer a".
Summary: I want CSS to be more DRY
No, it does not annoy me, because you can use multiple classes for an element and BOTH will match:
.idiot {
color:pink;
text-decoration:underline;
}
.annoying {
font-weight:bold;
}
/* and if you want to get REALLY specific... */
.annoying.idiot {
background-image('ann.jpg');
}
...
<div class="annoying idiot">
Ann Coulter
</div>
Personally, I find this a much more versatile solution to the problem. For example, in jQuery (or in another framework), you can add and remove these classes -- most commonly, you'll add a "selected" class or something that might do something like highlight a table cell, and when someone clicks to toggle it off, you just remove the "selected" class. Uber-elegant IMO.
In response to your edits, all you would have to do to remove the CSS from all of your A links would be to do something like this:
#message > div > a {
font-size:12px;
}
#footer > a {
font-size:10px;
}
Where the > symbol means "is a child of"
or, more generally (but this would also match an A directly inside #message and anything deeper -- the space means "is any descendant of")
#message a {
font-size:12px;
}
#footer a {
font-size:10px;
}
This is exactly what the Compass framework is good at. Sass allows variables, which makes coding/maintaining stylesheets very easy and a pleasant experience.
Have a look at SASS, which might do what you want. It allows for nested CSS structures, which can then be converted to CSS. I think.
In my opinion, the fact that you can't do this is perfectly OK because your CSS should remain as straightfoward as possible. On of the greatest advantage of CSS, as mention in Micheal Kay's XSLT reference (yeah xstl... I know), is that CSS is very simple and incredibly easy to understand.
I don't have to look at multiple places to know the styling effects of putting a class on a tag (well maybe but still).
So for me it would be a no for number 1. And as for 2, it has been discussed and I don't think it will be part of the standard.
css is not a programming language, it was never meant to be and (at this stage) never will be. what you're talking about has been discussed plenty of times before in W3C and WHATWG
oh and to answer 1) it doesn't annoy me
No, It doesnt annoy me, IE6 annoys me :)
It would be a useful feature to have, especially in a css framework, however, are we not being encouraged to lump all our css into one file now for "optimisation". I havent heard any rumours about such a feature in css3, but there is still a way to go on that spec yet, so who knows, it could make it in if you make enough noise now!