%HTMLlat1; %HTMLsymbol; %HTMLspecial; ]> Sass only really benefits people who haven’t mastered writing CSS properly
Roland van Ipen­burg
To be stolen or blogged

Sass only re­al­ly ben­e­fits peo­ple who haven’t mas­tered writ­ing CSS prop­er­ly

Fri­day 22 Jan­uary 2010 08:27

Har­ry Roberts is right. Sass is noth­ing more than a work-around for a work-around that CSS au­thors that know how to write prop­er CSS in the first place don't need. But we can't just blame the HTML mon­keys.

HTML and CSS thrive in an en­vi­ron­ment where every­thing re­volves around se­man­tics. In a work­flow where the con­tent is cre­at­ed first and more or less se­man­tic markup is added lat­er and fi­nal­ly that markup is used for styling, it all comes to­geth­er nat­u­ral­ly as in­tend­ed. But with to­day's fo­cus on cut­ting costs and thus reusable frame­works the process is of­ten com­plete­ly re­versed. In that sit­u­a­tion a CSS au­thor has to cre­ate a style sheet be­fore any­thing is known about the con­tent and the se­man­tics that will be forced in it. The only thing the au­thor then can come up with is a very elab­o­rate gen­er­al pur­pose col­lec­tion of rules and se­lec­tors that should be able to han­dle about any con­tent in an or­thog­o­nal and di­ag­o­nal way at the same time. Of course that will re­sult in an in­cred­i­ble mess of CSS for which you'll need all the help you can get to stay sane han­dling it. It's like de­sign­ing a data­mod­el in which you aren't al­lowed to do any nor­mal­iza­tion be­cause it has to be so gener­ic you can't tell what data is of the same type.

If you know what con­tent you're han­dling you can in a data­mod­el for ex­am­ple eas­i­ly tell sup­pli­ers, em­ploy­ers and clients all have some­thing that re­sem­bles an ad­dress, so you only need one gener­ic ad­dress type in your mod­el. CSS cre­at­ed in the re­verse work­flow can't tell yet if it boils down to the same type and has to stick with three seper­ate de­f­i­n­i­tions. Of course the nest­ing fea­ture of Sass comes in handy to de­fine that mess.

Vari­ables are some­thing that is in­deed miss­ing in CSS. But not in the way Sass aims to fix it. The prac­ti­cal use and na­ture of CSS of­ten lead to hav­ing to de­fine the same col­or val­ue to vary­ing prop­er­ties. If it's just about the same prop­er­ty it's pos­si­ble to gath­er all the se­lec­tors and de­fine the prop­er­ty in a sin­gle rule, but you can't link for ex­am­ple a bor­der-col­or and a back­ground-col­or so chang­ing a sin­gle val­ue changes both. What Sass adds be­yond that is a work-around for when the HTML mon­key isn't al­lowed to put ad­di­tion­al class names in the markup. Once you have de­fined the name of the vari­able in a mean­ing­ful way the same ef­fect can be achieved by us­ing that vari­able as an ex­tra class­name and add it to the se­lec­tors. The same is valid for mix­ins: Once you know why a sin­gle mix­in is used for sev­er­al se­lec­tors, the prop­er so­lu­tion is to fix it by adding the se­man­tics to the project.

But be­cause in the re­verse work­flow it's not pos­si­ble to give the vari­ables and mix­ins se­man­tic names, adding class­names breaks out of the il­lu­sion of seper­a­tion of con­tent and pre­sen­ta­tion. In the nor­mal work­flow you'll no­tice the se­man­tic re­la­tion be­tween el­e­ments first, and have no prob­lem adding those se­man­tics to the markup in the form of a class­name and hap­pi­ly use that as a hook for style in­for­ma­tion. The re­verse work­flow pre­vents that log­ic.

Vari­ables and mix­ins in CSS are of­ten a sign of la­tent se­man­tics. If the same de­sign is used for mul­ti­ple el­e­ments, a CSS au­thor should in­quire if there is a se­man­tic rea­son­ing be­hind it or the el­e­ments have dif­fer­ent se­man­tics and have just the same de­sign. In the re­verse work­flow this is fu­tile be­cause the de­sign­er just de­signs some gener­ic box­es and the CSS au­thor just styles some DIVs with­out car­ing about se­man­tics. And if CSS isn't based on se­man­tics it's all a bit point­less any­way. Then you get main­te­nance is­sues like a client wants to have pub­lic hol­i­days a dif­fer­ent col­or and the HTML mon­key wasn't even aware there were dates at­tached to his per­fect­ly styled gener­ic box­es. Often the only way out is then to blame some­one and tell the client it's im­pos­si­ble and screw ex­pe­ri­ence de­sign. You know clients who can't af­ford a cus­tom so­lu­tion can't af­ford ex­pe­ri­ence de­sign tests any­way.

What Sass is good at is mak­ing it eas­i­er to do by hand what tools like Dreamweaver are even bet­ter at. There is no point in writ­ing CSS by hand if that means you've thrown all the added val­ue of what that meant away and try to com­bine the brand val­ue of hand cod­ed CSS with the ease of gener­ic tools. No­body is in­ter­est­ed in a hand built Volk­swa­gen.


Book­mark this on De­li­cious

Add to Stum­bleUpon

Add to Mixx!



application away browser buy cool data days different flash game gta html ibook internet linux movie open play playstation possible run screen server side site stuff system train web windows work

Blog Posts (418)

Image Gal­leries

ipen­bug Last.fm pro­file

ipen­bug last.fm pro­file

Fol­low me on Twit­ter

Roland van Ipen­burg on face­book
Lin­ux Regis­tered User #488795
rolipe BOINC com­bined stats


Add to Google

Valid XHTML + RFDa Valid CSS! Hy­phen­at­ed XSL Pow­ered Valid RSS This site was cre­at­ed with Vim Pow­ered by Bri­co­lage! Pow­ered by Post­greSQL! Pow­ered by Apache! Pow­ered by mod­_perl! Pow­ered by Ma­son! Pow­ered by Perl Made on a Mac Pow­ered By Mac OS X XS4ALL This site has been proofed for ac­cu­ra­cy on the VISTAWEB-3000 Creative Com­mons Li­cense
This work by Roland van Ipen­burg is li­censed un­der a Creative Com­mons At­tri­bu­tion-Non­com­mer­cial-Share Alike 3.0 Un­port­ed Li­cense.
Per­mis­sions be­yond the scope of this li­cense may be avail­able at mail­to:ipen­burg@xs4all.nl.