andrew Posted…

Hardly a monstrosity. I wish I could have something (perhaps a PHP-backed UI) that abstracted things like "whitespace", "leading", and "color palette" out of the CSS files I've painstakingly written, then had to turn over to a services group. This would address simple things like making small typos in colors (#e433ff vs #e43eff for example) that it's easy to make.

This would result in a tool that would let my users make general changes to a set of complex CSS files in a more user-centric way: "I want to make the overall spacing between elements looser" or "I want to change from one color palette to another."

Nate Posted…

Just to be clear - I was joking about the "monstrosity" part, I really do think this is pretty cool.

I agree with your thoughts andrew - one could establish a css config file for the benefit of both your toil on the CSS, and ease of change for the less than CSS super proficient. Or I guess one could even make a mini php app that allows key folks to change variables via a friendly web page interface (it would just have to write the variables to a text file or db).

Lou Quillio Posted…

I used to do this very thing, in ASP (back in '98, before getting open-source religion). CSS support was weak then, and font-availability was shaky too. Since I was *styling font tags* at the time -- don't laugh, it was the right approach for a while -- and sweating font availability, a font-list string held in a variable did double-duty. Response.Write(serif1).

Of course, then you'd ratchet-up to functions that synchronized and wrote all attributes of the font tag. Once the functions were written and a few global variables set, in one stroke you could spit-out face, size, and color for Netscape and a somewhat more refined style attribute for IE4

But it was crazy, you know? Only made sense when it looked like browsers were permanently Balkanized and non-browser user agents were still conjectural. Saner living through script. Luckily, things have improved plenty, and scripted style rules are a dangerous vector for obsession.

An exception? If you gotta, gotta, gotta use fixed-pixel text sizing but still want to accommodate MSIE through a site widget. Seems to me that overcoming relative-sizing fear is easier, but hey ...

http://daringfireball.net/2004/04/preferences

LQ

Nate Posted…

This might be quite a bit less intrusive than the scripted font tag building you speak of Lou - first of all, it doesn't touch markup, secondly, it's primarily function is to establish global variables so that the CSS is easier to edit.

But on the other hand, I guess one could argue that you'd be littering your CSS file itself with all kinds of scripting, so in some ways it makes it things tricker for those wishing to do more than change your variables.

Lou Quillio Posted…

Nate, I'm certainly overstating the case, above. But I mean to deliver a warning: scripted style rules create a whole new abstraction layer, and may be the triumph of an idea over common sense

I think that only unbearable user-agent shortcomings should be scripted around, from a developer-productivity standpoint. It's just not difficult to replicate a stylesheet and globally replace a color rule. Right? If your stylesheet and overall scheme is so complex that scripting is justified, you can script the styles or simplify the scheme.

Guess I mean to say that I smell a justification for complexity as an end, and that the same end can be satisfied with less, not more. Been there.

LQ

Nate Posted…

Lou I see where you're going, and frankly you might be right in the end, but as I haven't tried this in a real-world scenario, I'm thinking there's a possibility that it might actually make things less complex.

Probably the best way to prove/disprove this for myself is to actually try it in some scenario. I'll give it a try in the coming days and will report back on my findings. Has anyone tried this with positive results I wonder?

Patrick H. Lauke Posted…

i've commented over at jeff's site already, but thought i'd put my GBP0.02 over here as well...

as interesting as this is (and hardly new...i've used this approach a few years back), the main problem i see is that the CSS that the script generates is not cached, requiring a call to the server every single time. this would negate the bandwidth-saving benefits of separating content and presentation, particularly with large stylesheets.

additionally - but maybe it's an unfounded fear - would this prompt designers to be lazy , not rely on the proper cascade, and just stick lots of unnecessary extra CSS rules in there...thinking that "hey, it's all controlled by a variable, so i don't need to worry about updating all those font-family declarations"?

Nate Posted…

Hmm. This bandwidth issue that you mention Patrick - it sounds like a deal breaker.

This is a bit of a stretch, but we could possibly still use the technique for large complicated sites that will be edited by different groups - as such:

• Flat non-dynamic CSS file (fully cache-able)
• Small PHP script which mostly contains CSS as is seen in flat CSS file, but also calls variables and includes a method to overwrite the CSS file when triggered
• A library of variables set either in a larger config file, or in a file by itself, includes a note that changing these variables requires going some URI to trigger the CSS file update

So maybe this could be a nice little "CSS abstraction" script, or maybe it would end up being a "CSS distraction" script - sounds like it might be worth playing around with tho.

As a sidebar - thanks again to Jeff Croft for bringing up such an interesting topic, be sure to check his site for the comments there if you haven't already

andrew Posted…

Along these lines, I'm reminded of a beautiful (Javascript?) implementation I once saw that tried to address some of the problems of other-people-messing-with-my-code after delivering a carefully styled site. It was essentially a Colormatch.dk-like color pallete chooser integrated into a CMS that spit out pre-rendered pages. It was pretty rad, and let site editors choose a base color for the palatte of a page, and the script determined other colors that matched.

Really, that's the kind of parameterization or "tunability" that I would like to deliver to the services group that consumes my css files. I'd be thrilled if they never had to open the css files or edit them. We value quickness of deployment of our product in a customer's environment over fine-grained visual tweaking, and so a dumbed-down UI with a color picker, some values for general whitespace, and some font control would be ideal

Nate Posted…

While we're on the topic - it's probably worth noting some alternatives and like-minded tech that's already out there. What came to mind immediately is:

• The CSS editor that is part of Textpattern (Screenshot)
• Well made non-intrusive CSS desktop apps such as StyleMaster

Of course, what we are talking about here is a much simpler, and more abstracted style editing tool, but it's worth taking note I think.

patrick h. lauke Posted…

Nate wrote:

Small PHP script which mostly contains CSS as is seen in flat CSS file, but also calls variables and includes a method to overwrite the CSS file when triggered

yup, i suggested that over at jeff's page:

a) have two stylesheets. one traditional, which is cached; the second one this processed PHP style only for the minimal rules that you wish to be dynamically set.

the idea per se is not bad, it's just that care needs to be taken on how it's used, as with everything.

Jason G. Posted…

I used this sort of technique with ASP a while back. It was for a slightly different purpose. I needed the class names to be dynamic more so then the actual styles. I was creating a XHTML/CSS web based calendar using the CSS example in "Eric Meyer on CSS: Mastering the Language of Web Design" and there are some styles that are based on the previous and next month (to make those days cells darker then the current month) and a server side scripting language was exactly what was needed, since the days/months were all dynamic, the CSS also needed to be dynamic. Worked like a charm!

Lou Quillio Posted…

Nate wrote: A library of variables set either in a larger config file, or in a file by itself, includes a note that changing these variables requires going some URI to trigger the CSS file update

No need for a special trigger, just link-in the default styles from a static file then link-in the custom rules from a pHp script. The first will be cached because it's probably sending a Last-Modified header, the second won't because it's probably not. Perfect maximization of caching- and scripting-benefits. This also casts Jeff's technique in the proper context: an extra.

• Header Checker at SearchEngineWorld.com
• Good info at Web-Caching.com

LQ

Mike Posted…

Nate Posted…

Mike, that should be do-able, it's just some math to be applied to the hex number specified. Not that I know what that math would be. Although Pixy sure does, just look at his Color Scheme tool.

Jeff Croft Posted…

Nice to see that I at least inspired some discussion!

I'm not claiming that this is a great real-world solution (I've never actually tried it), nor am I pretending that I'm the first person to ever come up with this concept. Since I made the post, a number of good reasons why this may not be a great idea have been brought to my attention. Still, I think it's an interesting proof-of-concept, and while my example for it's use (defining color/font variables to be reused) may be very simple, perhaps to the point of being more trouble than it's worth, I do believe there are probably some great uses for a script acting as a CSS file.

Anyway, thanks for noticing my humble little site and thanks to all of you have have commented on the idea!

Jeff

Rodrigo Contreras K. Posted…

I've created an alternative to implement CSS variables... Watch this: http://www.simov.cl/rc/blog/?page_id=115