PHP CSS Framework thoughts

by oneafrikan on February 15, 2006

A while back while doing some reading, I came accross an article written by Mike Stenhouse over at Content with Style, which got me thinking about this CSS malarkey.

Yes, there are only so many layouts that people want.
Yes, you should re-use code as much as possible. You should also write maintainable code. Modular code is also a good idea – we like modules.
Yes, it’s a good idea to use conventions as they make life easier.
Yes, client want to see stuff as it is developed, and they want to see progress as quickly as possible.
No, I don’t like more donkey work than I have to – I’d rather be solving problems I haven’t already.
and yes, anything that makes life easier is worth keeping around.

At the time, I also had 3 more projects that required similiar layouts and thus similiar markup – we’re not talking web applications here, but web sites that were either plugging into a CMS backend or were just static. So I started thinking some more…
What if I could abstract Mike’s modular approach using php? Would that make it easier to get a project done, or quicker, or both?
Could I put the config stuff into one php config file? I only want to make changes in one place…
I already use a config file to manage the usual site stuff that I don’t want to have to manually edit sitewide, would adding the css stuff above to that file make sense?
If I keep it all in a nice Subversion repository, then drop into a new project before starting or as and when I need it, would I make my life easier? Would delivering projects be faster?
Every time I learn’t something new, or somebody somewhere posted a solution to a problem, I could add it to the repo…. right.

And that made me happy, ‘cos my gut feel was that it would make things easier, and would definitely make my life easier.

Then I read some more, and came accross the “No more css hacks” article over at Stylegala and I started thinking how much css hacks pissed me off. Although a necesary evil (Sorry Tantek – your solutions are beautiful compromises to the ugliness of browsers that don’t play nice together), I just don’t like ’em – the result is code that looks like it’s been through the martian shredder in “War of the Worlds” … ’nuff said. But the reailty of the situation won’t change anytime soon, so we’re still stuck with a problem where I want the code I write to look beautiful (however much my talent is limited) so that I am happy and so that I can manage it better.
[Listening to David Heinemeier Hansson at the Web Apps Summit last week really struck a chord with me – I like to write beautiful stuff. It makes me happy and when I’m happy I’m more productive.]

Then I read some more, and came accross the Defining CSS Constants with PHP article written by Tyler Hall, and the pennies started to drop from the slot machine…

What if I combine the modularity of the CSS framework, with the “CSS hack killing” that you get from knowing what the user agent is before you spit out the CSS, with some constants that I define with PHP but spit out in the CSS… and then add in some standard stuff that just makes life easier for me. The result would be something that I could use for static or dynamic client sites, making donkey work easier and delivery sooner; as well as something that I could use as a starting point for a truly modular, flexible, better blog (in WordPress we trust) theme; and if I wanted to extend it some more, I could use it for a certain web app too. And hey, if someone likes it, and they add to it to make it better, then all the better for everyone.

So here I am – I’ve put a few hours into it so far, but not done as much of the above abstraction as I would have liked, but I’m still pleased with the results – I’ve probably saved myself at least a few hours to a day on any new client work, and any more time I put into it will add to that time saving.

For now I’m going to get the above stuff nice and smooth like, but this is what I’ve got earmarked to add later:
add print stylesheet
add mobile / pda stylesheet
add more layouts if it makes sense
abstract doctype definition
abstract main menu items into an array
abstract local menu into an array
add google analytics

There are differing points of view – some would agree with the approach, whilst others would say it’s not worth doing, so I’m curious as to what you think?

6 comments

No need to apologize. The fewer hacks you use, the better.

Tantek

by Tantek on February 15, 2006 at 10:21 pm. Reply #

Hey!

I did not get everything single thing you were say, but, i got most of it. Now, this is why, i have decided to build my own CMS, which i do believe, regardless of what you are building, be it static, dynamic, we app, everything falls back on ‘system running’ somewhere be it php/mysql or you hacking the html to ‘update a clients’ site.

I have so far, managed to seperate css/php/mysql, moreso business logic/data logic/presentation, I am happy about that.

Hmm, I wonder if I am responding to your question though,,, well I have thougth of making php spill my css, but then I thought, why am I a making an application do design work, sure it does not really do it, but what if somebody is running your site from a backup? not online?

truth be told, i like making things do what they were built for, period. nothing more. which is why i would not watch television on my computer, why? so why want php to do your css? you might as well install mysql 5, and run all your business logic in the stored procedures and get rid of business logic in your php?

my point? seperation is a good thing. i’d say make php choose the css you want to use as in the file that contains css, but not let php generate your css, nahmean?

okay, so it’s 2 am; and I just got back from drinking,,, *sic!

by lebogang nkoane on February 16, 2006 at 1:06 am. Reply #

on hacks: my *preferred* approach is to stick to standards and allow for the fact that different users may see different things – clients don’t seem to think like this, though ;)

on phporlizing your css: makes sense to me! as long as it’s maintainable (and being modular will certainly help that) and understandable (chas once gave a great seminar about writing maintainable code)

I do take lebogang’s point about mixing layers, but I reckon you can put *tools* traditionally associated with one layer to work on another layer, as long as you don’t mix the *layers* as a result (i.e. keep your funky css-rendering php separate from your page-rendering php)

by d@vid on February 16, 2006 at 12:45 pm. Reply #

Tantek

Yea, I guess that’s what I’m trying to think of / make work here – if the end result is nicely formatted and beautiful css, because you’re using php as a filter instead of hacks, then I think that it’s a fair compromise…

by Gareth Knight on February 17, 2006 at 11:01 am. Reply #

Lebogang

A wise old Jedi once told me never to mix your metaphors, and so it is with code – it’s never a good idea to mix your business/data/presentation layers, so that’s not really my intention.

I guess I’m trying to make life easier for myself, the modular framework gives choices and makes starting a project faster; whilst the php takes away some of the pain that css can create when you have large files that require heavy lifting or are employing hacks for different browsers…

– the end result should be to drop the files into a folder, and have a working project that you can get up and running quickly – having all the things you need at your disposal. Whether it be an internal or client project…

Your final point is well made, but there could be two ways to do the same thing:
– either create a css file that works as intended for each browser, using the browsers user agent to spit out the location of the right css file (but then you have to maintain multiple css files for different browsers)

– or create one file that spits out the correct css depending on the user agent, where you may have one file to manage…

I’m not sure yet which which is the best approach – perhaps some experimentation is necessary before getting too carried away…

by Gareth Knight on February 17, 2006 at 11:14 am. Reply #

d@vid

Clients don’t like that, no; at least not in my experience… sometimes they even expect you to be able to do magic as well… ;-)

As for mixing layers – I think you’re spot on – my feeling is that everything is a tool, and can and should be used as and when it makes sense – we write code to do processing for us, and to automate things – so it should do one of those things… and I’d never even dream of putting css-renderig php together with page-rendering php – they’d both be separate, disparate and maintainable on their own…

;-)

by Gareth Knight on February 17, 2006 at 11:18 am. Reply #

Leave your comment

Required.

Required. Not published.

If you have one.

Protected with IP Blacklist CloudIP Blacklist Cloud