Tutorials on CSS Templates
October 14, 2004 8:44 AM Subscribe
How to design for CSS: can anyone direct me to a resource on learning how to think about designing templates for use with CSS? Particlarly, how it's best to subdivide your page into divs and spans, and when to use a div id vs. a div class?
I'm a web programmer and want to be able to create at least half-way decent pages, pending the chance to get a real designer to polish them. I've read various CSS tutorials, and know how to use its various elements. but not when... I haven't found anything on-line that helps with what I'm asking.
Does anyone know of a book or anything on-line that'd help me get the fundamentals of designing CSS-friendly templates?
I'm a web programmer and want to be able to create at least half-way decent pages, pending the chance to get a real designer to polish them. I've read various CSS tutorials, and know how to use its various elements. but not when... I haven't found anything on-line that helps with what I'm asking.
Does anyone know of a book or anything on-line that'd help me get the fundamentals of designing CSS-friendly templates?
I figured out ids and classes just recently. The clue is that an id identifies a unique thing, while a class identifies a type of thing. If something will be used repeatedly and you want to assign it a look, then give it a class. If there will be one particular instance of a thing on your design, it will be unique and needs an id. An id is more powerful than a class, if there needs to be resolution between the two applying to a particular section of text. This is because an id is more unique than a class, and the more unique elements win in css.
posted by websavvy at 8:51 AM on October 14, 2004
posted by websavvy at 8:51 AM on October 14, 2004
NotMyself: neat site. Hadn't seen that before. Have you used them? If so, is the HTML bloated oldschool code with spacer pixels and whatnot? All the templates seem to include HTML but none make mention of a CSS file (though I suppose the file could live in the HTML).
posted by dobbs at 9:12 AM on October 14, 2004
posted by dobbs at 9:12 AM on October 14, 2004
I really enjoyed reading Designing with Web Standards by Jeffrey Zeldman. It really changed my understanding and philosophy of using CSS.
posted by jpburns at 9:33 AM on October 14, 2004
posted by jpburns at 9:33 AM on October 14, 2004
Ignore my question, above. I see they have a sample you can download. The code's a hodgepodge of CSS and tables. Not bad but could be better.
jpburns, I thought that title was the most verbose book I've ever read in my life, no exageration. I must have uttered "Why doesn't he get an editor?!" about every 3 pages. Painful, painful stuff. Unfortunately, yes, there's much to learn from the book so it should be read. I also like Eric Meyers (non-O'Reilly) CSS books.
posted by dobbs at 9:48 AM on October 14, 2004
jpburns, I thought that title was the most verbose book I've ever read in my life, no exageration. I must have uttered "Why doesn't he get an editor?!" about every 3 pages. Painful, painful stuff. Unfortunately, yes, there's much to learn from the book so it should be read. I also like Eric Meyers (non-O'Reilly) CSS books.
posted by dobbs at 9:48 AM on October 14, 2004
A really good book for you to check out is Web Standards Solutions by Dan Cederholm.
It has a lot of really good nuts and bolts information with solid explanations as to why one hunk of code might work better than another.
posted by ssmith at 10:07 AM on October 14, 2004
It has a lot of really good nuts and bolts information with solid explanations as to why one hunk of code might work better than another.
posted by ssmith at 10:07 AM on October 14, 2004
Holy CSS Zeldman! Sorry to dump a list of links on you, but you might find what you're looking for in there.
posted by tirade at 10:07 AM on October 14, 2004
posted by tirade at 10:07 AM on October 14, 2004
This is one of the best round-ups of structural HTML/CSS references:
http://dezwozhere.com/links.html
Just today, I ran across this:
http://www.maxdesign.com.au/presentation/liquid/index.cfm
The same folks have put together quite a few useful tutorials on specifics of web design, such as styling lists as navbars, etc.
It's worth pointing out that any tag, not just DIVs, in an HTML document can take an ID and a class. In fact, they can take multiple classes, which can be used for some clever styling tricks but can also make your brain hurt. So if you have your main navigation in a UL element, you probably don't need to wrap that in a superfluous DIV just to style it. Just call it, say, <ul id="navbar">
posted by adamrice at 10:28 AM on October 14, 2004
http://dezwozhere.com/links.html
Just today, I ran across this:
http://www.maxdesign.com.au/presentation/liquid/index.cfm
The same folks have put together quite a few useful tutorials on specifics of web design, such as styling lists as navbars, etc.
It's worth pointing out that any tag, not just DIVs, in an HTML document can take an ID and a class. In fact, they can take multiple classes, which can be used for some clever styling tricks but can also make your brain hurt. So if you have your main navigation in a UL element, you probably don't need to wrap that in a superfluous DIV just to style it. Just call it, say, <ul id="navbar">
posted by adamrice at 10:28 AM on October 14, 2004
I'm an OSWD fan as well; my last 2 weblog designs [self-link] have come from them; this current one being all CSS -- no tables. It *does*, however, render weird in IE5/6; the mainline entries slide to the left as you go down the page, for no discernible reason. NS7 and Firefox render it fine.
Konqueror blows it's top; now I understand why a) pros get so much money and b) people complain about Konq.
posted by baylink at 10:39 AM on October 14, 2004
Konqueror blows it's top; now I understand why a) pros get so much money and b) people complain about Konq.
posted by baylink at 10:39 AM on October 14, 2004
Re: Class vs. ID. Say you have a menu with 1st and 2nd level elements. The whole menu would be wrapped in 'class="menu"'. Each 1st level element would have 'class="level1"', each 2nd level element would have 'class="level2"' and the page you're at right now would have 'id="active"'.
And for maximum accesibility, you'd build the whole menu as a UL.
Then, the desiger would figure out how to display each level of the menu and the active page.
posted by signal at 11:26 AM on October 14, 2004
And for maximum accesibility, you'd build the whole menu as a UL.
Then, the desiger would figure out how to display each level of the menu and the active page.
posted by signal at 11:26 AM on October 14, 2004
signal, you can do way better than that. Your menu is UL (of course technically, ul as we're rolling XHTML now) with an id of "navigation" or whatever. The elements in the menu are described thusly in the CSS:
ul#navigation {
styles
}
ul#navigation li {
styles
}
ul#navigation li li {styles}
Zeldman's book (which is a great start) describes the other approach as "classitis". It beats the hell out of nested tables, but you can do better.
websavvy's got the class/ id thing well summarized. I will add this: if you're coming at it from a programming perspective (especially OOP), think of classes as a superclass or abstract class and ids as actual instantiations of a type. That may only make sense to me and it might not be particularly helpful while trying to learn, but as soon as I find a style definition that appears in two or more similar elements, I try to abstract that out into a class they can share.
You can also apply multiple classes to a single element by saying class="class1 class2" (so you've got multiple inheritance too) but be aware not every browser can handle that. NS4 chokes on it and some older IEs only apply the first class. And if you try to apply multiple classes at once through javascript (e.g., object.className = "class1 class2") you better be targeting a browser other than IE.
Last tip: develop in Firefox or Safari or Opera, get things right and then learn to work around IE's broken box model. You can alleviate some IE pain by forcing IE into strict mode by declaring one of the DOCTYPEs IE recognizes as needing strict mode. Then you only have to fix stuff for IE5 and IE5.5 (if you care about them). A bonus to using Firefox/ Moz is Chris Pedrick's amazing Web Developer Toolbar. Tools > Web Developer > CSS > View Style Information will turn the cursor into crosshairs. Pointing the crosshairs anywhere on the page will show you the element currently under the crosshairs, give you its CSS dependency path in the bottom of the browser and (when clicked) pop up a new page listing all the style declarations affecting the element, along with the line number they appear on in each file they're from. Don't know how I worked without it.
A Note on Style: you certainly aren't obligated to follow my convention above, but I find "nesting" elements in the CSS by lineage helps to debug inheritance issues and makes a CSS file easier to scan. If you arrange things by the order the root-level elements appear on the page (topnav, sidenav, content, footer, etc) in the CSS and then nest their children between, things are easier to find and understand later on. Also consider breaking CSS up into discrete files: one or two for the all pages on the site, then files for certain areas that appear throughout the site but not on every page, then files for individual pages that have a lot of style work (or one file for a lot of individual styles). Everything goes into CSS files. No style blocks at the top of a page (unless it's a proof of concept) and never, ever use inline styles
posted by yerfatma at 6:00 PM on October 14, 2004
ul#navigation {
styles}ul#navigation li {styles}ul#navigation li li {styles}Zeldman's book (which is a great start) describes the other approach as "classitis". It beats the hell out of nested tables, but you can do better.
websavvy's got the class/ id thing well summarized. I will add this: if you're coming at it from a programming perspective (especially OOP), think of classes as a superclass or abstract class and ids as actual instantiations of a type. That may only make sense to me and it might not be particularly helpful while trying to learn, but as soon as I find a style definition that appears in two or more similar elements, I try to abstract that out into a class they can share.
You can also apply multiple classes to a single element by saying class="class1 class2" (so you've got multiple inheritance too) but be aware not every browser can handle that. NS4 chokes on it and some older IEs only apply the first class. And if you try to apply multiple classes at once through javascript (e.g., object.className = "class1 class2") you better be targeting a browser other than IE.
Last tip: develop in Firefox or Safari or Opera, get things right and then learn to work around IE's broken box model. You can alleviate some IE pain by forcing IE into strict mode by declaring one of the DOCTYPEs IE recognizes as needing strict mode. Then you only have to fix stuff for IE5 and IE5.5 (if you care about them). A bonus to using Firefox/ Moz is Chris Pedrick's amazing Web Developer Toolbar. Tools > Web Developer > CSS > View Style Information will turn the cursor into crosshairs. Pointing the crosshairs anywhere on the page will show you the element currently under the crosshairs, give you its CSS dependency path in the bottom of the browser and (when clicked) pop up a new page listing all the style declarations affecting the element, along with the line number they appear on in each file they're from. Don't know how I worked without it.
A Note on Style: you certainly aren't obligated to follow my convention above, but I find "nesting" elements in the CSS by lineage helps to debug inheritance issues and makes a CSS file easier to scan. If you arrange things by the order the root-level elements appear on the page (topnav, sidenav, content, footer, etc) in the CSS and then nest their children between, things are easier to find and understand later on. Also consider breaking CSS up into discrete files: one or two for the all pages on the site, then files for certain areas that appear throughout the site but not on every page, then files for individual pages that have a lot of style work (or one file for a lot of individual styles). Everything goes into CSS files. No style blocks at the top of a page (unless it's a proof of concept) and never, ever use inline styles
posted by yerfatma at 6:00 PM on October 14, 2004
This thread is closed to new comments.
Hope it helps!
posted by NotMyselfRightNow at 8:50 AM on October 14, 2004