Never use .CSS files again
MachII---AKA really really dynamic style sheets---
Recently I blogged about they new way I am serving XML data to my apps and, thinking along those same lines, I decided to serve up the .css “files” in much the same manner. The need to deliver completely separate styles to the same layout is not that uncommon if you are writing an application that will give the user a choice of “skins” (as we do on InstantSpot.com ).
Here is a basic run-down:
Let's say, we have an object “Skin” which has, as one of its attributes, Style. Style contains the actual css info that would normally be housed in your style.css (or whatever you called it) style sheet.
Now, we have a layout that needs to link to some style sheet, or we would have a pretty plain looking site. Normally there would be a link to a file under the web root like:
<link rel="stylesheet" xhref="/skins/style.css" type="text/css" />
Since, in this scenario, we don't really have anymore style.css anywhere we need to have some new way to style our site. One possibility, we could create a Mach-II event called “style.css” that pulls that data from the Skin object, and passes it on to the view.
<event-handler event=”Style.css” access=”public”>
<notify listener=”StyleListener” method=”getStyle” resultArg=”CSS” />
<view-page name=”showCSS” />
</event-handler>
ShowCSS is simple a cfcontent and a cfoutput much like my other dumb XML view.
<cfcontent type=”text/css”>
<cfoutput>#event.getArg(“CSS”)#</cfoutput>
And finally, we can now link in that new style sheet via our Mach-II event.
<link rel="stylesheet" xhref="/index.cfm/event/style.css" type="text/css" />
voila...no more style.css files.
I have used other methods for using dynamic data in a stylesheet before but there is something beautiful to me about using the Mach-II event. Also, the .css extension on the event name might appease the validators out there.
PS. There is more to this story, stay tuned for the real reason we needed “really really dynamic style sheets”
Is my think right?
Similar concepts apply for files in your CMS. Serve them dynamically (with CFCONTENT) if you need to (like because they have access control restrictions), but if they're generally available, write them out to disk and let the web server do it. Particularly with larger files thish can be a significant performance gain because CF has to wait for the whole file to be sent before it can reclaim that thread to process another requests, even if all it's doing is reading off the hard disk.
What you can do is still use CSS files and then create alternate skins and dynamically choose which skin to use or use smaller partial css blocks that override the default css settings.
Another thing that people often forget about css is the use of class chaining, such as <p class="mySiteP section_1">, then by using dynamic settings in the template, just change the second in the chain such as <p class="mySiteP #dynamicSectionVar#">, which will apply the default first style and dynamically apply the specified 2nd style.
Where partial css blocks come in handy is in the use of custom tags that create UI elements. Through an initialization parameter set in the request scope,
I only output the CSS once for the tag in the "START" execution mode of the tag and then set the initialization param. So if I use the same tag in multiple projects, I don't have to remember to extract out the bits from the CSS file and if the tag is used multiple times on the page, the css is only generated once.
"What hasn't been pointed out and what is probably obvious is that you've just killed off the css cache from the user's perspective."
If the mime type is text/css, and by all respects the browser sees this as a css file (even having a .css extension!), how can you explain that the browser would ignore this and repeatedly request it? I am trying, but I just can't see it.
That being said, you can send a "cache until" header with the CSS from CF and browsers won't request it again until that time is up, which can reduce your bandwidth. Of course, the downside is that browser's wont request it again until the time is up, which means updates won't take effect when expected.
Loading....