CSS Frameworks and Semantics
It is interesting to see the debate that was more common in the CF world now move to the CSS community. Why shouldn't you use a CSS framework? Funnily enough, pretty much the same (mostly lame) reasons raised in the CF world. It is OK not to know everything going on under the hood as long as it doesn't come back to bite you, and a little extra CSS to download is a small price to pay for more rapid development for most use cases. That said, I still don't like OSS CSS frameworks.
Smashing magazine has a good overview of the topic (as usual, the comments are as instructive as the article). The issue I have with CSS frameworks is that they are usually not semantically meaningful (well, if you want to be pedantic, their semantic meaning refers to the positioning rather than the meaning of the content).I want to have meaningful divs with names like header, primary navigation, secondary navigation, primary content and the like, so if I decide to move primary navigation from the topbar into a left or right hand sidebar it doesn't affect my content (why should it - it is only a presentational change). There are issues with such an approach (often you need to put content like a "testimonials" pod into your secondary navigation area), but it's better than just having names like topbar and sidebar for your divs.
What I'm working on now is a framework that'll work for most web apps that'll allow us to have semantically meaningful HTML while still having flexible CSS and not having to start from scratch with each project. I'll keep you posted on how it goes!
It helps to keep things as semantic as possible. Let's say you have your primary content area:
div#primarycontent {
width: 400px ;
}
but on one page, the client (cause they are crazy) wants to mess with it. Traditionally, I would come up with an alternate DIV name like: primarycontentalt or primarycontentsmall, but this has NO semantic meaning. The better thing, I am seeing now, is that you put an ID on your body:
[body id="careers"]
... and then in your CSS, you simply update the primarycontent CSS with a more specific rule:
div#primarycontent {
width: 400px ;
}
body#careers div#primarycontent {
width: 550px ;
}
Now, the CSS remains highly semantic, but very flexible due the usage of body tag context.
ANyway, this kind of rocked my world cause its a total departure from how I normally do things so I thought you might be interested. Especially when it comes to things like "sidebar"; you could still just have "secondarycontent" but then in body context it floats left and in other body context it floats right.
ps. good luck with the world tour.
Commission? I love the sound of that! I'll have to bring it up to Dan Cederholm. Lets see if he has the money to pay what I want though! ;) Hope you guys are doing well and that you both are enjoying the book. Dan Cederholm did a great job with it. I know he has something else he's cooking up but no one knows yet what his next book will be on.
Yeah, I just recently noticed Smashing Magazine. All the posts I have seen are top quality design and CSS style posts. I gotta start paying attention to that.
http://www.code-sucks.com/css%20layouts/
for variations on a theme. This person has layed out a bunch of combinations for header/footer/content/nav.
Took 45 minutes to drop YUI Grids into our layout templates correctly, then the rest was cake. I'll be bringing this up during Ignite MAX on Sunday.
I can't see trying to build a large site from scratch without it.
Yes definitely make sure that site is bookmarked. Without a doubt that website you should be visiting everyday to see if there is anything new. You have no say in this. :) Once I'm back from MAX, the day after I'll be moving into my new place so I'll be settled. We'll have to meet up then doing some CF chatting and some celebrating.
My formula is something like this: Always use strict mode doctypes. Start with a baseline css file that works for standards-compliant browsers. Create additional css files containing any overrides necessary for individual browsers, and use server-side UA detection to determine whether to serve them. Don't use hacks to create browser-specific styles.
One technique I use that is maybe a little unique is that I give every structural element a classname, and when I reference them I include every ancestor class in the selector, as follows:
.Home .Content .Sidebar .SidebarInnerWrapper .Links{}
These selectors get pretty lengthy, but they make it very easy to tell at a glance what elements will be affected by a particular selector - kind of like a namespace for the element. (As long as you're disciplined enough to enforce it yourself!) Note that I also restrict myself to only using class selectors. A big issue I used to run into a lot was that other developers couldn't figure out why their elements were being affected in ways they didn't anticipate. Then they'd have to dig through a huge style sheet to figure out what if their element was being referenced by ID or class name, whether it was being affected by some global selector or descendant selector, etc etc. On top of that, .Net auto-generates element ids for controls, so a class name is your only option in some cases. Even though css gives you a variety of ways to skin the proverbial cat, I find it best to sharply limit which ones I use when it comes to creating a framework to be used unpredictably.
Using a CSS framework doesn't mean that you can't give meaningful names to your xhtml elements. For instance with YUI, most of the styles are class names, not element or id styles, which means you can not only give whatever IDs you want to your elements for your presentational styles, but you can also stack additional styles on top of the yui base classes.