Hello, I was just wondering if anyone could refresh me on this sort of CSS syntax: .name1 .someothername {properties} #idnamegoeshere .aclass {properties} There is no comma separating the classes or the class from the id. Why would we do this? Will "someothername" defined here only work if it is WITHIN something (i.e. a div) that has a class of "name1"? So can it be inside a paragraph with that class (we can't nest paragraph tags..) or must it be inside a div? Or am I completely wrong, and this is the same as saying .name1, .someothername {properties} #idnamegoeshere, .aclass {properties} (The difference being the comma.) Thank you!
You're working your way down the tree and through the parents to the children. someothername is a class and if an element is named that and contains a child with the class name of name1 then it receives the properties. Inserting the comma means all elements of the class someothername and name1 have those properties applied.
Thank you! But if I might add, what parent class attributes (is that the right word?) are there that I can use? Div - yes paragraph - no, no nesting (ignore the form stuff) Anything else that's obvious?
The class has nothing to do with what the element is. "class" is just a name (attribute) assigned to an element to be referenced by the browser for assigning CSS properties. You can give any element the same class name, not taking into account whether the applied CSS would work on that element or not. Parent/child relationships only refer to the outline and structure of the HTML. If a <div> has a <p> element inside it, then that <p> is a child of the <div>, as an example. Similar to a company organization chart.
Thank you so much again!!! I just have one very last question that I can't find an answer for anywhere else really... Is this sort of practice looked down upon? i.e. to nest like that, while it would save maybe some lines of CSS, do many people do it? Does it just make code more jumbled in most people's opinion? Is it something you might want to stay away from, even if it doesn't violate syntax? Again, thank you so much for your help.
Quite the opposite, NOT doing that is often looked down upon. A common example I use to explain why you'd build that way, and why we look down on targeting everything directly - you'll often... OFTEN... OFTEN come across this type of asshat nonsense. <div id="mainMenu"> <ul class="menuList"> <li class="menuItem current"><a href="\" class="menuAnchor">Home</a></li> <li class="menuItem"><a href="\products" class="menuAnchor">Products</a></li> <li class="menuItem"><a href="\forums" class="menuAnchor">Forums</a></li> <li class="menuItem"><a href="\faq" class="menuAnchor">FAQ</a></li> </ul> </div> Code (markup): The ONLY class that should be neccessary in the above code is current, and the DIV isn't even needed. <ul id="mainMenu"> <li class="menuItem current"><a href="\">Home</a></li> <li><a href="\products">Products</a></li> <li><a href="\forums">Forums</a></li> <li><a href="\faq">FAQ</a></li> </ul> Code (markup): 99.99% of the time anything you can do to a DIV can be done to the UL directly so axe the div and move the ID to the UL - If you are going to have a bunch of elements in a row all get the same class, they shouldn't even have a class in the first place, style off their parent element - NOWHERE is this more true than when it comes to LI, TD or TH. Comparing the first one to the second one in terms of targeting elements in the CSS: .menuList - no longer needed... Wasn't needed in the first place! .menuItem == #mainMenu li .menuAnchor == @mainMenu a Net result is it means less markup - since markup is not cached across pages on a website, and CSS is, moving all that nonsense out of the markup means faster loads of subpages. (usually to the point it makes a lot of the bullshit people are using AJAX for these days seem completely pointless) You might also have multiple elements that are a 'date', so you give it class="date" - well, what if the ones in your content are going to get different styling than in your sidebar? Both are type date, both may share some properties the same... Both could also have different values. .date { padding-bottom:1em; font:bold 95%/120% arial,helvetica,sans-serif; color:#0C0; } #content .date { text-align:right; } #sideBar .date { padding-top:1em; text-align:center; } Code (markup): Makes for less code overall since you aren't restating values. NOT using those types of constructs is frowned upon - since as I've said many times, not every element deserves a div around it or a class on it... Just as George Carlin said not every ejaculation deserves a name. The latter part describing the code generated by a lot of people. You asked "Does it just make code more jumbled" - It may make the CSS a hair more complex, but not needlessly so. The reason that increase in CSS complexity is acceptable is that it makes the MARKUP simpler, and opens the door to better use of concepts like separation of presentation from content. Since NOTHING in the markup of a modern page should be saying how things are going to appear. That's CSS' job!
Using descendant, child, sibling and other selectors is the preferred method. That's why it's called cascading style sheets. See http://www.w3.org/TR/CSS21/selector.html and http://www.w3.org/TR/CSS21/cascade.html These are key to the use of css. cheers, gary
This has been amazingly helpful, I have already fixed loads of old uploaded code thanks to all these replies! deathshadow raises one more question though, do you then look down upon the generic page container which is pretty much just a blank div? I'm not sure if I should remove these from old sites too (are they even necessary for relative positioning? I thought you needed a parent container at least)
Depends on what you mean by a 'blank div' - sometimes you might end up throwing in an empty div like <div class="topBorder"> just because you've run out of existing elements to put presentational hooks on... That's just the nature of the beast. I guess what I was saying is that you shouldn't resort to them around single elements if it can be avoided... If you mean just wrapping a div around a bunch of elements and doing little with it directly, That too is fine. Remember what DIV stands for - DIVISION. It's primary job is to group together a bunch of like elements into sections, dividing them from other sections. Sections can contain sections... so take your average blog entry... I often see people do: <div class="header"> <div class="title" align="left"><b>Blog Entry Title</b></div> <div class="date" align="right">Today, 5 January 2010</div> </div> <div class="content"> Whole bunch of text here<br /> <br /> Some more text </div> Code (markup): Which is WAY too complicated for it's own good, and certainly not semantic markup. Done what I would consider properly that would be turned into: <div class="article"> <h2> <span>Blog Entry Title<span> - </span></span> Today, 5 January 2010 </h2> <p> Now, a couple of paragraphs marked up as paragraphs is much better </p><p> At least, I seem to think so </p> <!-- .article --></div> Code (markup): Both elements are part of the heading, so put them in a HEADING tag. For CSS I'd make the h2 text-align:right; and to wrap floats, then float the first span left - moving them onto the same line without the need to clear it. The nested span "h2 span span" I'd set to display:none, since that's for graceful degradation when CSS is disabled. the outer DIV in this case serves it's job well, we are grouping together a bunch of semantic tags as a single element. These tags don't get our nice comfy wrapping element like the UL in a list, so having a hook to apply a class is nice if for no other reason than to avoid having to throw in a bunch of classes targeting everything directly. To compare the first one to the second one: .header .title == .article h2 span .header .date == .article h2 (kind-of) .content == .article p (kind of) Sometimes you might want that extra DIV for the content in there though - adding borders, backgrounds, or padding that you do not want applied to each paragraph individually for example. In that case: <div class="article"> <h2> <span>Blog Entry Title<span> - </span></span> Today, 5 January 2010 </h2> <div class="content"> <p> Now, a couple of paragraphs marked up as paragraphs is much better </p><p> At least, I seem to think so </p> </div> <!-- .article --></div> Code (markup): Is entirely fine if the CSS is going to be something along these lines (padding and margins are assumed to be reset): .article { background:#CCC url(images/topGradient.png) 0 1.5em repeat-x; } .article h2 { overflow:hidden; /* wrap floats */ zoom:1; /* trip haslayout, wrap floats in IE */ padding:0.25em 0.5em; text-align:right; font:normal 100%/150% arial,helvetica,sans-serif; color:#FFF; background:#008; } .article h2 span { float:left; font:bold 120%/125% arial,helvetica,sans-serif; /* 125% * 120% = 150% */ } .article h2 span span { display:none; /* hide CSS off elements */ } .article .content { background:url(images/bottomGradient.png) bottom center repeat-x; border:solid #008; border-width:0 2px 2px; } .article p { padding:0.5em; } Code (markup): Since there could be more than two P, applying a bottom gradient to each would look silly, but applying it to a #content div wrapping our paragraphs means we don't have to play around with either. Likewise the border around them is easier to apply than trapping just side border on the paragraphs and bottom border on .article. Also handy if you are going to have non-paragraph content like UL, other headings like H3, or elements which might not warrant a paragraph tag like a 'more info' type link. It's not a matter of not using the generic containers of DIV and SPAN, it's a matter of not using them when you don't have to. This is actually one of the 'promises' CSS3 brings to the table, in that with multiple backgrounds and CSS generated content a lot of the stylistic sandbags and wrappers we have gotten used to applying for CSS2 are no longer needed. Damned shame that CSS3 won't be real world deployable until sometime around 2020 (given how long it took for CSS2 to be real world deployable and that CSS3 is still in DRAFT) - but we can dream.
Thank you once again, this has been so helpful to reiterate. And yeah, I asked because I was taught before that you should encapsulate like an addict. Kind of like creating functions for only one or two lines of code. Some of my code, for example, is (soon to be was!): <div class="node"> <div class="content"> <div class="page"> <p>asfasf</p> </div>...etc Code (markup):
Which CAN make sense in a compiled language - which is where a lot of these incorrect ideas come from. Unfortunately PHP, Perl, Javsascript, and even HTML are INTERPRETED languages, so a lot of the optimization rules from the compiled language world do more harm than good - which is how fat bloated rubbish libraries like jquery or mootools came into being. the overhead of a function call in an interpreted language is six to eight times that of in a compiled language - so wrapping every little call in a function can drag your program right under. It's why that stupid $ prototype thing in javascript is a complete disaster and little more than driving with the parking brake on. HTML not only has the parsing issues of being interpreted in realtime - it compounds that problem further with the REAL bottleneck - bandwidth. Extra wrapping div, extra classes, it all adds up to more elements than needed meaning longer pageloads, a larger DOM, slower javascript thanks to the larger DOM, slower application of CSS effects, and less efficient use of caching models. Nowhere is this more evident than when you have multiple instances of the same thing across multiple pages. If you are using the same basic template and elements on all your pages, if the layout is entirely in the CSS and the presentational images (borders, logos, icons) are pre-cached, you'll use a hell of a lot less bandwidth and load a hell of a lot faster on your subpages since the only thing that has to be sent is your content and it's markup. I actually have a formula I use to determine the 'upper limit' of what a page should be assuming it has no complex form elements like selects. 1k + content size * 1.5 + 150 bytes per IMG + 400 bytes per OBJECT. When I say content, I mean the text without tags. Best way to pull up that number is to open the page in opera, copy to the clipboard, then paste into an editor (like crimson editor) that gives you the size. Opera beats FF and IE in this regard since it does it's best to give you plaintext without any extra formatting bull. (Firefox is actually the worst for this). Images in that formula should be 'content' images, aka images unique to that page and not part of the 'theme'. Object of course refers almost entirely to flash embeds. If a page goes past those numbers, it's probably poorly coded. I can usually come in under those numbers WITH comments still inlined and formatting... Most developers? They come in at four times those numbers with no comments and white-space stripped. Take the main board index here at digital point. 14.3k of content, currently five content images (some smileys) - the rest of the images being presentational and as such belonging in the CSS. By my formula there is NO good reason for that to be more than about 23-24k of markup. I might be inclined to up that to 30k just because there's a god-awful amount of anchors on the page - but that still doesn't begin to explain the 117k used by this vBull theme. Though the outdated method of including CSS so netscape 4 ignores it, tables for layout even on the non-tabular data, classes on every damned element even when they all get the same and have a perfectly good ID or unique handler on their parent, TD with a class, bold or colspan instead of TH, TD with colspan instead of caption, use of non-breaking spaces instead of padding, javascript to do CSS' job on the menu, tables to do lists job on the menu, spans to use a inline STYLE attribute, spans to apply classes that could just as easily be applied to their parent anchor on the user list, and use of deprecated tags like ALIGN do a hell of a lot to explain why it's easily four times as much markup as should be neccessary. A rewrite using the methods I advocate (and that our recently departed friend championed) could EASILY reduce a forum like this one's server handshakes 50% or more, and reduce bandwidth use up to 70-80%. I know this because I applied these same types of changes to a high traffic SMF based forums, and in the process, well, cut server handshake (aka file requests) in half and bandwidth 72%! Though it could be worse - we could be talking the rubbish markup of your average wordpress template or the crap that wordpress has hard-coded into it outside the templating system like the asshat absolute links (which are mostly just covering up for the inept directory structure of the system)