Contextual CSS Is Good When You Know Everything About Your Content

I wrestled (still do) with this exact issue. How to create widgets that may be added anywhere in an application/page and style them easily.

I felt giving each widget its own container (typically a div) and id or class resulted in additional, and some cases unnecessary markup - since the parent container may be all that is required to apply the styles. However in the end it turned out to be the most practical solution.

I also adopted a CSS layout framework (960grid - but there are many to choose from) that certainly speeds layout and gives new users a common starting point.

Maybe this is a no no, but for me, when I want more intelligence in my CSS, I use some jQuery helpers. Obviously I have a base style sheet that covers 90% of what I'm after. (Maybe more like 99%.) But for that 1% where I need something specific, and I don't want to hope it works cross browser I:
$('div.mainNav ul > li:first').css('color:red;');

Or something of the like.

I figure it's about on the same line of having JS help with the sizing of objects to make sure they all line up correctly. (Like getting the tallest pane in a tabset, and setting them all to that height so there's no "jumping" when switching tabs.)

Another benefit, though I haven't explored this, would be the ability to setup variables, to be reused in the styling. Which is something I've always wanted in CSS.

I do not see many that is using cfm files for css? I surely helps when you want variables :)

I sometimes do a style.cfm like this:

<cfset primaryColor = "blue">
<cfset stdBlockMargin = "4">

<cfheader name="content-type" value="text/css">
<cfheader name="expires" value="#GetHttpTimeString(now()+ CreateTimeSpan(0,8,0,0))#">
<cfcontent type="text/css">

.myClass{
color: <cfoutput>#primaryColor#</cfoutput>#;
width: <cfoutput>145 -#stdBlockMargin * 2#</cfoutput>px;
margin: <cfoutput>#stdBlockMargin#</cfoutput>px;

}

If you cache it, performance does not really suffer. I have not seen any browser that gets confused when the stylesheet is .cfm instead of .css, but I can on the other hand not say I have tested it, or used it, very much since most designers get violent when they see something that looks like programming code. I do use it as templates to generate a static .css though

Ben,

I would propose that instead of trying to make a single all encompassing framework that you look at dividing your needs. Create a base framework which defines the core, the immutable, parts. Then look at additional css to define certain aspects.

In my opinion the core is where contextual CSS is best used and something more explicit (or still semantic but constrained) is stored in additional files.

That said in the end it really is about what works best for you.

Good points Ben.

I've found that "namespacing" CSS helps quite a bit when developing a generic css framework. For a really good example of this look at the CSS created by the jQueryUI widgets.

Also another bit that I find very useful is that items can have multiple classes (and your CSS can match on any combination of them).
For example <input class="my-widget-lib my-widget-button" /> will match to css selectors .my-widget-lib and .my-widget-button.my-widget-lib

I felt giving each widget its own container (typically a div) and id or class resulted in additional, and some cases unnecessary markup - since the parent container may be all that is required to apply the styles. However in the end it turned out to be the most practical solution.In my opinion the core is where contextual CSS is best used and something more explicit (or still semantic but constrained) is stored in additional files.

Ist of all i want to say its really a very informative post. But i want to adding that if we should use external CSS. Because internal css is not makes our codding some complex when in looks. So we should avoid internal CSS as possible.

@Jon, I do that a lot. I often define classes like

.left{float:left}
.border{}
.noborder
.clear
.parent
.bold
and so so that I can do <div class="myMainClass left border"> so I can have variations on my base classes without writing a new class name.
In some ways maybe it makes the css less "pure", but it is better than using the style="" for exceptions and better than writing a new rule for one exception. It is also possible to override for instance 'bold' at a certain place in the css if that is absolutely necessary.

I give all my widgets an id anyway, and all the main sections of a page, so it is easy to do

#main h3{}
#section2 h3{}
#section3 h3{}

What I am trying to do most currently is to keep everything that has to do with sizing and positioning separate from appearence, like font and colors. Usually you make a lot more changes in the appearence sections, so I keep them in separate stylesheets (and merge+minify them at the production servers)

I actually have one stylesheet for each "widget" also, unless it is very insignificant. I found there is less risk of mistakes like that and if I want to change the default behaviour I do that in my "overrides.css"

So I usually have a 'main' css that includes all the parts, like
structure.css
appearence.css
widget1.css
widget2.css
overrides.css

And then my merger can take a look at main.css and merge everything in there into the live.css

I guess there is better ways, but it seems like each time I want to improve it, it just get's more complicated :)

Good points. I'm going through this now as I wanted to define a div#main_content p {} contextual selector for about 90% of a site's copy, but there are certain areas it shouldn't be styled that way (line-spacing, text-indent, stuff like that). Since I won't be maintaining this site forever, I probably won't go this route as anyone after me who puts in a paragraph (even with its own class) down the road will wonder why it is inheriting default styling they don't want. To make things more confusing, the CMS in use is in a highly vertical industry application and requires edits by the hosting web team (external developers like me have to request changes by email). So in this case contextual selectors aren't really the right option, despite their obvious power, cleanliness, and simplicity.