Understanding some css basics

Hi group,

I'm diving in to more formal learning of css. I can figure out how to make changes I need to make edits to websites by use of the firefox inspect tool, but I must admit I have no formal knowledge of the basics and could not write css from scratch if I had too.

So I have a really basic newbie question that has been burning for a while I thought I would ask.

When I look at some css, I see three major differences in the way a line of code starts that confuses me.

Some code starts with a #, some starts with a . and some start with nothing at all. Can someone help explain the differences?

For example, here is some random css I scraped out of a file.

img {
  -ms-interpolation-mode: bicubic; }

#map_canvas img,
#map_canvas embed,
#map_canvas object,
.map_canvas img,
.map_canvas embed,
.map_canvas object {
  max-width: none !important; }

Code (markup):

 

# targets an ID.
. targets a class
no character indicates a tag.

This: #test { color:red; }
would target: <div id="test">This is red</div>

This: .test { color:blue; }
targets: <div class="test">This is blue</div>

this: div { color:green; }
targets: <div>This is green</div>

values separated by spaces mean "child of", so this:

#test span { color:yellow; }

targets the span inside #test thus:
<div id="test">Not yellow <span>Yellow</span></div>

You should also be aware that ID's trump classes and classes trump elements without classes... so this:

div { color:green; }
.test { color:blue; }
#test { color:red; }
#test span { color:yellow; }

With this markup:

<div class="test">This is blue</div>
<div>This is green</div>
<div id="test">This is red <span>This is yellow</span></div>

Would render as expected. All DIV are set to green, but the ID and the class trump values set on a tag, so they are the colors as set. The inner yellow span still happens because we targeted the child of #test.

All of this is called "specificity" -- learning how to use it is very important, so you don't end up doing idiotic dipshit bull like the crap turdpress vomits up.

For example, you'll often see nonsense like this:

<div id="mainMenu">
	<ul class="menuUL">
		<li class="menuLI"><a href="#" class="menuA current">Home</a></li>
		<li class="menuLI"><a href="#" class="menuA">Forums</a></li>
		<li class="menuLI"><a href="#" class="menuA">FAQ</a></li>
		<li class="menuLI"><a href="#" class="menuA">Links</a></li>
	</ul>
<!-- #mainMenu --></div>

Code (markup):

Which is bloated half-assed bull (no matter what the dipshits at turdpress claim) since if every element inside a parent is getting the same class, NONE of them need classes! Likewise it's not like UL isn't a perfectly good block level container, so it's not like it needs a DIV around it (unless you're nesting constrained width in a full width style). 99% of the time there's no legitimate reason for something like that to be much more than:

<ul id="mainMenu">
	<li><a href="#" class="current">Home</a></li>
	<li><a href="#">Forums</a></li>
	<li><a href="#">FAQ</a></li>
	<li><a href="#">Links</a></li>
</ul>

Code (markup):

"#mainMenu li" would be the same as ".menuLI" in the original. "#mainMenu a" being the same as ".menuA" -- and of course #mainMenu would be #mainMenu and .menuUL combined. The only reason that code like that first example even exists is developer ineptitude and a complete failure to grasp what you are asking about -- specificity.

Which to my mind means you're asking all the right questions.

Now, guessing your next question, you might be asking what the difference between a class and ID actually is...

As a rule of thumb classes exist for the sole purpose of applying style. You can use the same class many times in your markup, and really they should be left for when items are recieving unique style compared to it's peers -- like the "current" class in the above example. You should avoid adding classes unless you REALLY need them and have used up all your 'semantic' tags and 'inheritance' first.

ID's on the other hand exist not just for the application of style, but also so you can target them with a hash in a url (href="#mainMenu"), and for targeting with scripting. Id's must be unique, which means you can only use an ID once in the markup. Personally I like to use ID's on major unique subsections of a page people might want to navigate to, like #mainMenu, #content, #disclaimer, #links, and so forth. Classes I use for things like a current element, or to apply common stylings like that on 'subsections'.

One big thing to remember is semantics -- just as your tags should be chosen in your markup to say what things ARE, you should do the same with your classes. Don't use classes and ID's that say what things are supposed to look like, since that appearance may not apply to all your different layouts, media targets, or even different skins that share the same markup.

Hope that clears it up a bit.

 

Wanted to reply thank you, I have to absorb what you wrote a little more.

Off the top of my head, can something other than span be used in what you wrote below?

#test span { color:yellow; }

targets the span inside #test thus:
<div id="test">Not yellow <span>Yellow</span></div>

 

I always get by with a little help from my CSS friends. LOL I've been dabbling in it for years, and still have a lot to learn. I'm grateful for this explanation. Thanks everyone.

 

Just replace SPAN with another class or ID or whatever you want. For example right now I'm doing a forum skin (SMF) where I've got this:

.buttons a span {
  display:inline-block;
  vertical-align:middle;
  width:18px;
  height:18px;
  margin-right:0.2em;  
  background:url(images/icons.png) 0 0 no-repeat;
}

Code (markup):

Which means all spans inside anchors inside a class called 'buttons'.

So:

<ul class="buttons">
  <li class="markRead"><a href="#"><span></span>Mark Read</a></li>
  <li class="delete"><a href="#"><span></span>Delete</a></li>
  <li class="move"><a href="#"><span></span>Move</a></li>
  <li class="reply"><a href="#"><span></span>Reply</a></li>
</ul>

Code (markup):

All of those span will display the icon.png. The classes on the LI are used thus:

.buttons .delete span {
  background-position:0 -18px;
}

.buttons .move span {
  background-position:0 -36px;
}

.buttons .reply span {
  background-position:0 -54px;
}[/code[

Sliding the background around to reveal different parts of the images -- the so called and incorrectly named "CSS Sprites"; many images in one file, allowing for less handshakes (file requests) and faster page loads.

This illustrates how the same elements can be targeted different ways. The values from ".buttons a span" is applied to all of the span in the example as they are span inside anchors inside .buttons, while the second set of CSS targets them individually for the values that are different between them. That's one of the reasons to use classes or ID's, for when elements or their children are different from their siblings and children. If the element or it's children is NOT different from it's siblings or children, don't waste time putting a class on it... or an ID unless you want to target it with scripting or an on-side hash link.

Code (markup):

 

A small quibble:

I'm pretty sure you meant to say, "descended from". The child selector is ">".

cheers,

gary

 

While that is the technically correct term for a space "descendant selector" I find it confuses a LOT of people -- particularly if they come from an OOP background... since a descendant in OOP inherits all properties and methods of the parent; technically correct on some values which default to :inherit, but not on all.

There's a lot of language in the specification like that which is all well and good for the browser makers, but leaves people trying to build websites scratching their heads -- see how they use the words "deprecated", "importance" or "empty"... "empty" is a great one since an empty tag is one that cannot contain content, not one that does not contain content; what seems like a subtle philosophical difference that led to hordes of the "XHTML is XML" idiots not grasping that:

<div></div>

Is NOT an empty element by the specification's meaning. It's like how courts will use the word "arrears" when 90% of the population outside a courtroom has no clue what the word even means.

But what can one expect from a specification for building websites that's written for the browser makers instead of the people ACTUALLY WRITING WEBSITES!!! Let's the browser makers shove us around and be their bitches when really the relationship needs to be the other way around -- like HTML 4 STRICT intended... of course that's why HTML 5 came into being since they really prefer to be pitching instead of catching...

Hell, let's face it, with the whole HTML 5 garbage the W3C is turning into the type of filth that would not even have the common decency to give... ok, I'll stop there.

 

Hello tom11011! Your question is why we use # dot and some place we started our css without # and dot.
Actually # use for ID. Dot use for class and we use start css without # and Dot its use for html tags for example body, a, span, label etc. To know more about css visit this website www.w3schools.com its very helpful for you.

 

Don't underestimate the power of CSS selectors to begin with. I notice guys at work, and I'm sure this happens elsewhere, but they mark up their code with classes/ids everywhere because they are too amateur to write the selector that targets the element they want. Really the only time you wouldn't be doing it this way, is when you know the location might be moved around, but outside of that...blindly using classes/ids everywhere is just lazy and makes ya look inexperienced.

 

As I learn css, I've been wondering if there might be an easier way. Can you supply a basic example of putting this tip to use?

 

There is a big assumption that you will always have access to the HTML file that needs styling. And if you don't, there may also be the possibility that there aren't a lot of classes and ids to work with. This leaves you with no option, but to get clever with the CSS selectors. An added bonus is that this keeps the HTML lean.

I know this is a simple example, but it shows the concept. So let's say you wanted to change the color of the phone number and this was your HTML:

<div></div>
<div>
   <div>
      <ul>
         <li>text</li>
         <li>text</li>
         <li>phone number</li>
         <li>text</li>
      </ul>
    </div>
   <ul>
      <li>text</li>
      <li>text</li>
      <li>text</li>
   </ul>
</div>

HTML:

From my experience, most people would throw on a id or class onto the <li> tag if they wanted to do such a thing, but you don't have to because CSS knows where it's at:

div + div div ul li:nth-of-type(3) {...}

Code (markup):

Now for some people this probably not easier, but this is more universal than trying to figure out why someone named a tag the way they did. Just remember when dealing with CSS selectors, you have a lot of power with the operators, nesting, and pseudo.

 

I would advise against going quite as radical as that example -- saying what things ARE to target them can make life easier. See the UL example in my post above - could I use nth-child instead of the classes? Yes... is that easier to keep track of? What happens if I change the menu items or their order, I then have to rewrite the CSS! It's mostly about knowing where to draw the line.

Of course, if I had that many DIV and that little semantic markup, I'd put a bullet in my head -- and I still don't trust adjacent sibling selectors (+) or child selectors (>). Really though the lack of content to say what the markup should be makes it VERY hard to say what the proper markup for that would be.

 

Haha yeah that might have been a little overkill, but it was simply to show the concept and the power of CSS, and even then that was a light selector.

Of course you want to mark up stuff so you know what it is, but don't get into the habit of marking things up just because. I don't know how many times I've refactored my code only to find unnecessary classes/ids all over the place.

I rarely use >, but + is the cat's meow.

 

That's why I believe in the "content first" approach as step two is semantic markup; only adding div and span at the CSS layout creation phase AS NEEDED. I'm always shocked how people seem to slap DIV around perfectly good block level containers like H1, UL, FORM, and so forth for no good reason. You need it to not mix width and padding at the same time, or because you have more visual properties than will fit on one tag, or can't rely on generated content thanks to IE bugs -- sure, add the DIV or SPAN... But other than that I'm always flabbergasted at the sheer number of DIV, SPAN, ID and classes people use for no good reason.

... well, there is a reason... might not be a good one. Again to borrow from Ike: Ignorance, apathy and wishful thinking.