I’ve noticed that my posts are quite verbose and vague at times, so I’m going try something new. Reduced verbage, more examples and less (maybe) soapboxing.
My post on CSS and dynamic page construction drew a comment about how I was an idiot for not using CSS. The problem is that I never said that we weren’t using CSS. CSS is a great technology, just not for certain types of web sites. You’d think I’d be able to explain my position a bit better, but it took Matt (our Sytadel technical lead) to come along and explain it a bit better by asking a few important questions. So let me try again.
Think of a web page, which contains the following:
This is emphasised.
Assume it contains some CSS selectors like the following:
P { font-family: Tahoma, Arial, Helvetica, sans-serif; font-size: 10pt }
EM { color: red; font-weight: 200 }
DIV.photo IMG { margin: 0.5em }
These selectors state that paragraphs will be in Tahoma, EM elements will be in red, and IMG descendants of DIVs with a class of “photo” will have a half em margin.
Now assume the above HTML fragment is placed inside a web site which has a completely different branding, yet we still want the HTML fragment to display as it would on the original site. Perhaps the new site is an aggregator for other sites, or a portal with previews of other sites.
We now have problems. How do we specify red EMs for the HTML fragment? The obvious solution is to wrap the fragment in a DIV with an ID or CLASS, and change the EM selector to a descendant selector:
EM { color: red; font-weight: 200 }DIV.fragment EM { color: red; font-weight: 200 }
This fixes the EM, but what about the other infinite number of combinations? Perhaps we just take the style sheet and prefix everything with the DIV.fragment descendant selector?
DIV.fragment P { font-family: Tahoma, Arial, Helvetica, sans-serif; font-size: 10pt }
DIV.fragment EM { color: red; font-weight: 200 }
DIV.fragment DIV.photo IMG { margin: 0.5em }
Unfortunately this doesn’t take into consideration the initial default CSS settings for all the standard HTML elements. For example, the original site uses the default for TH, a centred bold, yet the new site has its own definition, a left aligned pink. Now we need a DIV.fragment TH selector in the stylesheet, which resets every CSS attribute for TH, so it looks like the initial default state. Likewise, our fairly short P selector would now expand out to several dozen lines defining the default styles for a P element. I’m not even sure if that’s 100% possible to do, take an arbitrary CSS state and redefine it to the original initial default settings.
What if we wanted the new site to display the fragment slighty smaller inside a box on it’s pages? Simple, use a font-size: 0.8em on the fragment’s wrapping DIV:
DIV.fragment { font-size: 0.8em }
The problem with this though, is that the fragment already has a definition for a 10pt font size, so the new site has to know this, and remove it, along with any other definitions which conflict with it’s wishes. Then don’t forget to include all those CSS resetting definitions as well. Be careful of the ones that interact in mysterious ways, like how a TD can affect the style of a P, regardless of the cascade.
One last problem I’ll mention, and yes there are many others, is what if “photo” is also a defined class in the new site? So we now have to go through and rename all the classes, and update the stylesheet so there’s no conflict. At least this one seems easy enough to solve with some simple renaming logic.
All these problems go away of course, if the person coding the stylesheet knows what the final HTML will look like. This is the Zen Garden catch, you need to know what the code looks like, before you can start doing anything interesting. In some CMS environments, you don’t have that luxury, which limits what you’re able to safely do design wise.
Which brings me back to the original statement from my previous post which the anonymous comment poster took issue with: CSS is designed to be applied by designers who know exactly what is contained within the page. If you don’t know the CLASSes, the IDs or the hierarchy, then good luck applying any sort of design outside single element level embellishments, like site wide font size or background colour.
I think it is possible to design a layout and style technology which address these problems, and even amendments to the CSS standard could possibly get us most of the way there. But that’s best left for another post.
OK, so I lied about the soapboxing.
(Originally posted to Synop weblog)