If you’re a pro, it’s easy to forget the confusion you felt when you just started learning CSS. Just for fun, let’s try and remember some of those little weird confusing moments. I’ll start us out by listing some random ones I remember and have picked up on while helping others recently. Then you folks take it from there in the comments.
These aren’t huge big things like broken layouts in IE or which vendor prefixes should you be using. It’s the little fundamental stuff, like tiny differences in syntax that change meaning in a big way.
Tag qualifying
What’s the difference between these two things?
.class { }
p.class { }
The first one will select any element with that class name. The second one will only select paragraph elements with that class name.
The first is more generically useful. The styling you apply with that class may be useful to multiple types of elements. Even if it’s not today, it might be tomorrow. It’s also faster for the browser to understand and apply.
It’s a fairly rare case that you’d want to use the second example. It would only be if you wanted to re-use the same class name for multiple elements but have them to different things.
p.stand-out { background: yellow; }
span.stand-out { font-weight: bold; }
Selector order matters
Why are these so different?
.class div { color: red; }
div.class { color: green; }
The first example there is very different because of the space character between .class
and div
. The stuff before the space and the stuff after the space select different elements. The first part is “select any element with this class name” and the second part is “select any div”. Put them together with a space and you get “select any div that is a descendant of any element with this class name”.
The second doesn’t involve any of that descendant business. It’s a tag-qualified selector like discussed above.
If the above CSS was the only CSS on the page, the results would be like this:
<div class="class">
<h2>
<div>Would be red</div>
</h2>
<div>Would be red</div>
Would be green
</div>
<div>Would be black</div>
Why use ID’s at all?
It seems like as far as CSS is concerned, using classes and using ID’s is the exact same thing.
#id { color: red; }
.class { color: green; }
It’s just an attribute and it’s a seemingly arbitrary difference in syntax depending on which one you use. The results are predictable:
<div id="id">Would be red</div>
<span id="id">Would be red</span>
<div class="class">Would be green</div>
<span class="class">Would be green</span>
You might have learned ID’s are “supposed” to be unique, as in, only have one element per page that uses it. But you’ve slipped up before and it doesn’t seem to matter, the CSS applies just fine.
Then you start getting conflicting information. Some tools and philosophy teach that ID’s aren’t good for styling. Some articles tell you they are the most efficient. Perhaps you work with a JavaScript developer who tells you they need ID’s on everything because it makes their job way easier.
Confusion abound here. Turns out, everybody is kinda right. Here are the facts:
- CSS doesn’t care much which you use, as far as actually applying styling. ID’s are technically faster for a browser rendering engine, but other than the most extreme of circumstances you’ll probably never notice a speed difference.
- JavaScript cares very much about ID’s. It can be noticeably faster for JavaScript to find an element by an ID. And this is where the “uniqueness” is very important. JavaScript will only find the “first” element with that ID, so if you have multiple on the page, confusion may ensue.
- ID’s have an infinitely higher specificity value than classes. If there is an element with an ID and a class and they both apply styles, the styles applied by the ID will take precedence over the styles applied by the class. This can be useful, this can be a hindrance.
My personal philosophy is to use ID’s on stuff that I absolutely know there will only ever be one of and will not benefit from properties from a class name shared with other elements.
Buried hovers
What’s going on here?
div { color: red; }
div:hover div { color: green; }
:hover
is a selector which only applies itself when the mouse is over a particular element. What is weird here is that you don’t necessarily have to apply styles to that element being hovered over. In this case, we are applying styling only to descendant divs when the parent div is hovered. So:
<div>
I will be red all the time
<div>
I will be red, unless that top
div is hovered (but not necessarily me)
and then I'll be green.
</div>
I will be red all the time
</div>
Whitespace doesn’t matter
This:
div{color:red}
Is the exact same as:
div {
color : red
}
You do need spaces in selectors to make decendent selectors (e.g. ulli { }
is absolutely not the same as ul li { }
) but other than that you should use whitespace however makes looking and working with your CSS comfortable.
Notice the missing semicolon on that property in the example above. You can omit that if it’s the last property in the group. Personally I never do as if you add more property/values later and forget to add the semicolon to the previous line, that’s a problem. Because whitespace is so free, it will continue to read the next line as part of the value of the previous line.
Example of the problem:
div {
-webkit-border-radius: 10px
-moz-border-radius: 10px
border-radius: 10px
}
The whitespace is fine. The no-semicolon on the last one is fine. But the first two property/value pairs don’t have semicolons and will totally screw up and not work.
Property overrides
What font-size is the div going to have?
div {
font-family: Sans-Serif;
font-size: 18px;
font-weight: bold;
font-style: italic;
color: red;
margin: 0 0 20px 0;
font-size: 21px;
padding: 10px;
}
It’s going to be 21px. You’ve accidentally listed it twice and the second one is going to win.
Order in CSS file matters
If you have two selectors that have the exact same specificity like this:
.red { color: red; }
.green { color: green; }
And then they apply to the same element, the selector later in the CSS will always win. Class name order in HTML doesn’t matter:
<div class="red green">Will be green</div>
<div class="green red">Will be green</div>
What makes for a semantic class name?
The previous example used “red” and “green” as class names. That’s not very semantic. Why not? That’s a whole ball of yarn, for next week! ish!
Nice article, Chris. Learned something new about the order in the CSS file and that class names in HTML don’t matter :) Thanks!
Reminds me of when I first started. Well now a days we get to struggle when to use them new HTML5 elements!
Great article for the newbies out there and very well broken down.
I always enjoy finding articles like this one to share with people I am trying to help learn more about CSS. I find most people stumble on combining multiple selectors to make something more specific. Also, the “cascading” portion of CSS.
Thanks, Chris!
Thanks Chris, Great article.
I appreciate these basics may be a little painful for a CSS Guru to articulate. But for a CSS Hack like myself they are very helpful.
Cheers
Thanks Chris. Most of us will appreciate the common mistake being learned before it happens!
Thanks again Chris, I always enjoy reading your articles. You really are a great teacher.
It’s true, we must not forget that we all hard to start somewhere, so even though these are basic CSS tips, it’s great that you share them and guaranteed it will help more than one person out who is just getting started.
Another thing I see quite often in the code of newer developer’s is the following: #header #nav ul li a { } which can be written with just #nav a { }.
I have seen this as well and I believe it’s known as tag over-qualification. More than one id selector should never be necessary and it probably means the HTML is badly structured.
However it should be noted those selector orders you wrote are not necessarily the same thing and would affect styling differently.
#header #nav ul li a { }
would target the a tags of any list items in #nav whereas#nav a { }
would target any a tags within the #nav element. It is very possible someone would want to style links in lists differently than those throughout a whole containing element. With that in mind I’d say the most you could simplify #header #nav ul li a to and target the same thing is:#nav li a
That is, assuming #nav is not the id of the unordered list (ul</pre).I’m going to defend the ‘n00b’ designers here… And I’m going to disagree with Jeremy. There are very often times you will need to use more than one selector.
There’s a prime example. Targeting only #nav a {} wouldn’t work, and something more specific like #nav ul li a {} would be necessary.
Also, as far as reading the css, i appreciate those ‘extra’ selectors. It tells us the first coders original intentions more clearly, and it is by NO MEANS bad practice.
Thanks Chris! Brilliant ;-)
excellent graphic design blog! it was really helpful site for me :) thanks for sharing..
The thing that made coding CSS so much easier when starting out was learning shorthand properties, in particular: background, font, border, margin, and padding.
Just an addition to the “order in css file matters”
If we have a class like below
.red.green{color:#03F;} // will give blue to both elements
The color should be green but not happening getting blue color…
The color should be red but not happening getting blue color…
and
.red.green{color:#03F;} // will give blue to both elements
.green.red{color:#C0C;}// will be pink color to both elements even if above
//class is added first.
The color should be green but not happening getting pink color…
The color should be red but not happening getting pink color…
Hope this helps!
What the f*?!.
Why should the color become green when you name a class? If it is like you say, tell me how the color “house” or “tom” looks like :D
Hey there,
Thanks for this article! There’s a lot of great resources on the net. I was just wondering.
How many of you studied web design/development at university?
Is it possible to become a professional web designer without any tertiary education? Have any of you become professional just from getting stuck in and with the help of sites like this?
I personally am self taught, other than a vocational school class on basic html.
According to a poll Chris did, seems about 40% of web workers (at least those who read this site) are in the same boat. See the poll results.
i’m self taught as well with no formal training at all. i started with graphic design (self taught as well) then progressed into learning CSS/HTML 10+ years later. A few months after writing my first line of HTML, I started a web design biz with a friend and was forced to learn in the real world (or starve). That will get you up to speed quickly :)
I’ve been writing and designing HTML for about 3 years now and it landed me a job with a fairly large .com.
Great article Chris, even for non-newbies it’s good to have a refresher now and then as bad habits can sometimes creep in over the years!
Hi Chris,
nice roundup! what about this:
or
what does that mean?
greetings!
The first: the brackets are make for an “attribute selector” so that particular one means “select any element that has a class name that begins with “grid-” (e.g.
<div class="grid-25">
.) The up-arrow (carret) character is where “begins with” comes from. More on attribute selectors: https://css-tricks.com/5591-attribute-selectors/The second: The greater than symbol is called a “child” selector. As you likely know with HTML, elements can be nested. So you have a body element, and within that a div, and within that a paragraph. The nesting can get even deeper than that, let’s say: body > div > div > div > span. Now let’s say you wanted to style those div’s, but only the ones higher up the hierarchy, not the lower ones. If you did
body div { }
it would literally select all the divs throughout that entire hierarchy. If you didbody > div { }
it would only select divs that were direct children of the body (only one level deep). More about child selectors: https://css-tricks.com/5514-child-and-sibling-selectors/Thank you Chris for the break down on these. VERY useful concept to grasp and use for functional CSS.
great write up!
thanks
Child combinator.
Excellent CSS vocabulary overview: http://nimbupani.com/css-vocabulary.html
I recommend to explain it in evaluation order. I.e. right to left. It indicates what’s actually going on under the hood and it also starts with the eventually matched subject. (The specs also do it this way around, by the way.)
body div { }
Matches every
div
which is a descendant (space is the descendant combinator) ofbody
.body > div { }
Matches every
div
which is a child ofbody
.Nice! Thank you. Very helpful.
have been wondering this same thing now for awhile! thank you!
Nice and useful article, thanks a lot!
Nice one Chris. The ID’s vs Classes one was particularly interesting, as I had read an article (here) stating that ID’s were faster, yet had read articles elsewhere stating ID’s should never be used for CSS.
Like you, I tend to only use them when I know I am not going to share the class. Mainly just for my main layout divs, like my header, footer, navbar and main-content divs, for example. Perhaps it is purely a personal thing, but for these main layout items, I prefer to use ID’s and keep them towards the top of my CSS files, to make them easily identifiable.
All in all, a good read, thanks.
Hi chris,
Awesome article :)
I would like you to post something on e commerce solutions. (If possible.)
[Self copypasta from Reddit]:
IDs are only faster if they are the key selector (rightmost simple selector). In real-world cases there are usually at most 3-10 matches like that on one page. Even if it were indefinitely faster, it wouldn’t even save one msec.
That reasoning is the wrong way around. You should always look at the benefits first. If there aren’t any, don’t do it.
Neutral: There is no performance benefit and also no productivity benefits.
Negative: Adds an extra digit to specificity. Encourages you to write rules in a location specific style, which means they are cannot be reused ever.
IDs aren’t good for anything on the CSS-side.
Of course this doesn’t mean that they shouldn’t be used in the markup. You absolutely need them for fragment links and they also make a lot of sense for JavaScript.
Now, you might feel inclined to use them just because they are already there. However, this will negatively affect your CSS architecture. Draw a clear hard line there. Keep things as separated as possible. Resist the urge to reuse hooks, which were added for completely different purposes.
Do not introduce any kind of coupling (especially between completely unrelated parts of the stack) if it can be avoided and even more so if there aren’t any benefits whatsoever.
My understanding is that regular tag selectors at the end of a selector are what perform poorly, because rendering engines work right-to-left with selectors, not left-to-right. For instance:
#banner nav a {
...
}
You would think that the rendering engine would find
#banner
, then find anynav
elements it contains, then find anya
s they contain and style them, but it’s actually the other way round — it looks at everya
in the document one by one, sees if they are a descendant of anav
, if so sees if thatnav
is a descendant of#banner
, and if so styles thea
.(Credit to Steve Souders’s Even Faster Web Sites for teaching me that).
Yes, the rightmost simple selector (the so called key selector) is the entry point. The fewer elements it matches, the quicker the selector will be. Also, the quicker a false positive (i.e. partial match) is identified (e.g. by using the child combinator instead of the descendant combinator), the quicker the browser can continue doing something useful.
However, you cannot determine if a key selector will match too many (thousands) elements if you only look at the CSS. You need typical permutations of the markup for that. So, from the point of static code analysis (performed on the CSS with tools like CSS Lint), this isn’t something you can actually check. There is simply too little information available.
The only exception is the universal selector (
*
). Since it matches every element, it usually matches too many elements. Using it as key selector in conjunction with the descendant combinator is always a horrible thing to do – even more so if there are many nodes and the average depth is very high.Nice one there Chris — most people really get this wrong or forget the way it works — I learnt a thing or two myself :)
Just to mention that :hover doesn’t work for anything other than links in IE6. So div:hover will not work in IE6.
Just to mention that you shouldn’t be supporting IE 6 anymore ;)
Most of the time IE6 should not be supported, however well working with large international companies, the analytics should and will dictate browser support. Believe me I cannot wait til IE6 is gone, but in markets like china there is still 25%+ market share for ie6 and that is to big of a market to ignore.
Although I have now learnt all this with experience, this article would’ve been VERY useful to me when I was still a beginner.
I actually had none of these confusions. I started by reading a few books and then work my way up. So there was no confusion.
Although multiple divs using the same ‘id’ on the same web page might work ok from a css point of view – they won’t validate using strict mode. That’s the reason I prefer to use ‘class’ attributes for them in that situation.
Cheers
I
For some reason I always used to get confused between
.example .another { }
and
.example, .another { }
Now I know that the first will target:
While the second will target:
Very nice article. Refreshing for the old day. Thanks.
Great reminders as I prepare to start teaching CSS, Chris. Thank you.
“Buried hover” is interesting. I never really thought about it before, but using absolute positioning – for example – you can, say, change the content of a text block when the mouse hovers over a menu item somewhere else on the page.
It took me a while to stumble across specificity, which is an incredibly important concept if you want to cascade your styles properly.
My favourite article that cleared things up for me nicely: http://www.stuffandnonsense.co.uk/archives/css_specificity_wars.html
—
It takes a bit of practice before you can start identifying the best opportunities for creating reusable classes, but that’s an important leap as well.
—
When reusable classes are difficult or impossible for whatever reason (dynamically generated tags that you do not have direct control over), you can still make your CSS more maintainable by identifying patterns and grouping them together. This is particularly helpful for rules that share common characteristics, like headings:
CSS Lint tool suggests you shouldn’t style headings more than once.
Although I agree it’s more organized to define a font-family, maybe colors – any common style – for all headings then font-size to each one of ’em.
Why would it be wrong? Maybe CSS Lint doesn’t get that the headings are still “unique”?
I’ll add to what Jonathan pointed out. It’s easy to miss the all-important commas when you have a list of several selectors who share the same attributes. I still sometimes forget to put them where they are supposed to be and suddenly my page gets all wonky.
Is buried hovers cross-browser? :DD
I’m not sure about buried hovers, but I can tell you
:hover
can only be used on <a> tags in IE6 and lower, but from what I hear that’s becoming a non-issue as people abandon trying to support IE6.Yes, forgetting IE 6 (which you should not be supporting).
Amen to IDs for Javascript developers! jQuery flies when selecting IDs as compared to classes. DOM traversal over a few levels just feels bloated.
Why use ID’s at all?: Aren’t Classes better suited for styling things that are repeated often?
And ID’s for, as you put it, things that are unique or am I missing something?
For instance some common classes seem to be:
.clearThis { clear: both; }
.alignLeft { text-align: left; }
You may want to use ID’s for same page navigation, or as javascript selectors.
Great article, Chris! Thank you very much.
is it just me, or in the final example, shoule this line:
Will be green
really be :
Will be red
As the article states, the order in the markup doesn’t matter at all (unless you do something silly like
[class="red green"]{...}
). With the same specificity, the order in the CSS determines which one will override the other(s).2 eureka moments for me years ago.
1) Reset your CSS using one of the many CSS Resets out there. This will normalise all the browser default styles and give you a level playing field to work on in all browsers.
2) If you ever notice that a parent is not containing it’s floated children, try apply “overflow: hidden” or a “clearfix” to the parent.
1) Have a look at normalize.css rather than a reset.
2) I would recommend the clearfix technique over setting overflow: hidden; as that can cause unwanted problems.
Thanks for pointing out normalize.css to me. I’d never heard of it before. It looks promising.
I remember when I started using CSS, a UK developer handed me a bunch of files and disappeared! I was in distress, lol!
I kept practicing and eventually came to learn its intricacies. I remember learning all of this and it takes a while, but having this knowledge and power of CSS is wonderful.
such a nice article. Keep posting something useful. Thanks a lot
Great article, thank you! :-)
Nice article
thanks
Great article. Thank you for writing this. The article really simplified a few things for me. Also, I’ve never thought of buried hovers.
Keep up the good work…
This is one of those rare articles you find where you think “This is exactly what I’ve been looking for!”
I could have used this article back in the day!
Great article! I have just one year dealing with CSS and I perceive that I improved a lot in this time but I’m always learning with this basics articles. So thank you.
About ID versus Classes I like to abstract all elements and then determine whether will be a class ou id, trying to nest the properties properly.
Best
This is a great article! It’s refreshing to go back and think about the seemingly basic things like these – I definitely learned a thing or two from this article.
Nice article, Chris as always i do remember how confusing was !old days
Definitely remember being stuck with link hovers that didn’t work because I didn’t know the importance of the ordering of the link pseudo classes.
Then I learned, and came up with this memorable phrase to guide me: “Latex Volatile Histologist Aglitter”
Well, not really ;) I just created it a minute ago with the help of Jason Schramm’s wonderful acronym creator: http://www.jschramm.com/acreator/index.php
I never been confused by that, except I was usind IDs too much, I had stuff like #block_1, #block_2 instead of generalized classes. I am a little shamed by this, as it made code bloat and other guys who worked after me had problems.
Hello friend, can i learn a Simple CSS from you?
very useful post..Thanks!
The one for me is the specificality (is that the term? lol )
I always style elements trying to be as neat as possible (though the outcome rarely so !), so I often start styling homepage like this :
I dunno why, but i just think that writing that way increases the readibility by…. a bit lol. Of course problem appears when I’m moving to another page with different layout. Let’s say I’m on Gallery page where the #left heading will be a different color from homepage heading. So for h1 in the gallery page, I add a class=”gallery-heading ” then
And of course it doesn’t work because of the #content #left h1. So I had to either add #content #left .gallery-heading rule or omit the #content #left h1 rule and change it to more specific (like adding class home-heading or something) rule, both of them are as exhausting.
The term is specificity.
http://www.w3.org/TR/css3-selectors/#specificity (explains how to calculate it)
You are fighting a specificity war with yourself. The trick is to make everything less specific – not more.
Let me demonstrate this with a simple example:
And now you want to add some kind of task list to your main content. There can be several of those, therefore you use a class for that.
Whoops. Not specific enough!
Will work, but it’s more specific than it needs to be.
If you’d used a class for “main” you wouldn’t have had this problem in first place.
Does the trick just fine.
yep. that’s true. it’s just one of the bad habits i somehow can’t avoid completely.
css seemed easy for me when i started learning it. But then you need to learn some tricks to use it such as use overflow: hidden or use clearfix even for a simple two column layout. I wonder why css3 hasn’t come with a fix for this problem?
Check out the pseudo selector :after to clear your 2+ column layouts.
No additional mark-up is needed, and example:
http://nicolasgallagher.com/micro-clearfix-hack/demo/
Thanks for the link, Tim.
I was aware of a similar clearfix as it was posted sometime ago on this site.
I hope we will soon be able to stop using hacks for these things and just use plain and easy css to accomplish the floats and the desired layout, at least for modern browsers if not older versions if IE.
Brilliant. I’ve only been in the web developing game 6 months and for the first time I felt smart because I actually knew all of what you were explaining. If you remember back to when you were a newb like myself it’s not often you feel like you know alot in this game. Cheers
A small point , but you say “ID’s have an infinitely higher specificity value than classes”.
Not true. There’s nothing infinite about it. IDs are just 10 times more specific than classes. I’d suggest removing the word “infinitely” here, it’s misleading.
You could have eleven class names on an element, and that won’t “win” over a single ID. It’s not a base-10 system, it’s base-∞
Chris,
Do you mean 11 classes in the attribute like
or 11 classes in the selector like
where 1 to 11 are each descendents of the last?
In addition, I wonder what the ‘power of specificity’ might be for a multiple class selector like
Tremendous site BTW. I don’t know how you find the time to produce such consistent quality. Cheers!
Sorry, the first ‘pre’ bit came out blank, but you know what I mean ; )
Doesn’t matter if the element has 11 or 100 class selectors, one ID selector will win over it.
The example with no gaps (selecting multiple classes on one element) would also lose to an ID selector. But if you put eleven classes on one element and your still trying to style that thing with an ID selector, you’ve got bigger problems. : )
Oh by the way – for another newcomer tip – you can’t start class or ID names with a number.
I know it’s just an example but it is worth noting that .1 { } will never work.
They can start with a number. However, you have to escape them on the CSS side as Unicode. E.g.
<div class="5">...</div>
.\35{background:#f00}
More: http://mothereffingcssescapes.com/
Great idea for a post and I too learnt a little more about specificity here (RE the order of multiple classes in the attribute not affecting it). I think ‘specificity wars’ (using a Star Wars metaphor) is worth a chuckle when it comes to learning specificity.
The single most confusing aspect of CSS for for me was that of pseudo-classes – especially ‘:active’ since my original assumption was that it acted as a ‘you are here’ signifier (like out-of-the-box Drupal’s use of an active CLASS on ‘current’ menu links).
Anyway, I did a post about it called ‘Pseudo-class Deception’:
http://www.heydonworks.com/pseudo-class-deception
You forgot this mistake!
p {
color: blue
background: red;
}
(forgot the semi-colon)
HTML:
I will be browser default color and will not have a background color.
Just wanted to add that although you “can” use an ID more than once, it is horrible practice and will no doubt fail W3C validation. For those who think validation does not matter, it does. I have yet to have an instance that cannot be written to be validated.
To those who think ID’s should not be used at all in CSS, I do not understand this at all.
It is the fastest selector and if it is for a targeted area, say a background image or focal area I see no problem with this.
However CSS like any other language should be as abstract and reusable as possible. But just like those who write super heavy PHP classes or JS functions for one task, it is not always necessary.
Code should always be a simple as possible to complete an objective, less is more and keep things separated.
On another note, one mistake I made often when first starting out was in line styling, yuck! There is rarely if ever a need for this.
Yes, that’s what everyone thinks, but it actually isn’t true. First and foremost there is only a little bit to gain (compared to classes) if it’s the key selector (rightmost simple selector). If you got 1000 of those instead of 1000 which use a class, you gain about 1msec.
However, in the real world you typically only have about 3-10 id key selectors per page, which means you gain about 0.01 milliseconds (not seconds!) under ideal conditions.
Just to be clear:
#foo{}
or.foo #bar{}
are microscopically faster. Something like#foo .bar{}
is exactly the same as.foo .bar{}
in terms of performance.This means using IDs (on the CSS side) for performance reasons is pretty much the least worthwhile micro optimization you can think of. It’s so goddamn irrelevant, it isn’t even funny anymore.
Yes, it isn’t always necessary that something can be reused, but what’s the point of getting in the way of reuse? Keep in mind that you get absolutely nothing in return. You only make things more complicated than they need to be.
By the way, you got it the wrong way around. Maximizing reuse equals less work. It also means there will be less CSS (naturally) and less markup (surprisingly). There is less to write, less to test, and everything always looks consistent without any extra work (everything is build with the very same bricks after all).
Nice, Chris. I been using CSS for a few years now and it still hurts! That said, it’s power also wows me a often.
I shouldn’t says so in front of so many folks who do know CSS, but I often find trial and error faster than working out wtf is going on. :)
Am wondering tho, why are how are these different:
.myclass1 .myclass2 {}
and
.myclass1.myclass2 {}
thx
In that case, the SPACE makes all the different. The first one selects elements with a class name of “myclass2” that are decedents of an element with a class name of “myclass1”. The second, selects elements that have BOTH class names.
Woot! Got it! Thank you!
Interesting article. Learned some new stuff today. Thanks!
Dear Chris:
Really nice and helpful.
Sometimes everyone needs to go back to the basics.
id vs class. ID’s are particularly useful for emphasizing the importance of the following statement.
div{ this statement is worth 1 inheritance point }
.classname{ this statement is worth 10 inheritance points }
#idname{ this statement is worth 100 inheritance points }
Thus, assigning ID’s strategically throughout the markup is instrumental for keeping a larger-scale stylesheet easy to work with and straight-forward in the long run. Creating a complicated web of !important spam?
h2{font-size: 1.2em} = 1
h2.Title{color: red} = 11
#Content h2{color: blue} = 101
So from above example, the Heading 2 with class .Title and within the #Content container will be blue.
Specificity isn’t base 10. Just sayin.
Empirical data points in the opposite direction.
IDs aren’t the devil. They just make you think in a way which leads to solutions which facilitate annoying issues which wouldn’t exist otherwise.
Just watch some frequently updated website grow over a couple of years and you should be able to see these patterns. It’s always the same. It starts with bad abstractions and then new stuff is piled on top of the old stuff. Soon, people are unable to tell which parts are still needed and nothing gets removed ever.
Not using IDs slows the rate of degeneration down. With conventions, guidelines, and tools you can even achieve a complete stop.
Awesome article! Thank you <3!
Very good article for new comers
Chris – really useful. More of this, please!
Good read and worth passing along. Thanks for writing it.
One suggestion: in your last subhead, you have:
Order in CSS file matters
If you have two selectors that have the exact same specificity like this:
.red { color: red; }
.green { color: green; }
And then they apply to the same element, the selector later in the CSS will always win. Class name order in HTML doesn’t matter:
Will be green
Will be green
I think you mean for the very last line in this example to say:
Will be RED
Cheers!
Nope, they both will be green =) Try it!
Well, I’ll have to figure out how better to quote html in the comments, but subbing brackets, I think the last line should read
[div class=”green red”]Will be RED[/div]
This is one of those articles you don’t see enough of; the back-to-basics stuff for beginners!
It was fun to brush up on the basics!
Nice one Chris.
This one is great for a person who is new to CSS. People do ask these questions a lot :)
Chris
Thank you. refreshing to read this again and again. the details are still catching me off guard. I need to do some more projects from empty to finished instead of just modifying others’ projects.
Thanks Chris,
Learned new things from your post. Little details that make a difference. Feels like taking another step on the CSS ladder
I’m still struggling with CSS; given that I’m self-taught and have learned mostly by going through lines and lines and lines (and lines) of code, this kind of little gifts from you gurus to us noobs, just like this very post, are really appreciated. Thanks!
A nice intro for newbies to follow and start off with. You broke it down nicely for them to fully grasp CSS.
Maybe you could do a few follow ups with other tips?
It’s always good to have such refresher because those little stuff made me sick some times.
Great article, Chris! Good reminders for ‘not-so-new’ to CSS folks, too. I’d forgotten about the last one – the order in CSS matters. I also appreciate the clarification of how IDs do matter to javascript.
Thanks for the article man! appreciated it!
CSS is always one of the areas I never touched on, until in the past few months. I’m still learning, and I need to get more experience in the process.
On a sidenote, this tutorial is great – before I’d even finished reading
I didn’t know there were still people thinking about newbies (me) !
Great stuff! I thought it was for newbies and not for me at first, but there were a couple things I did not know. I wish I would have read this article when I was first starting out!
it was a nice article.
brushed up my basics ;)
use IDs when you want strict control and don’t want anything clashing – classes when you need general control over a larger spectrum…
web design is nuts
i love these kinds of articles :) keep em up :)
Great article – thanks so much. CSS is always tricky and there’s always something new to learn. This site makes doing so a joy, love it!
Nice article — thanks . Learn nice and good things for this article..