The solution we came up with was not too dissimilar to the one discussed in this months A List Apart article Progressive Enhancement with CSS and that article is well worth a read. But I also thought I’d write a little about the setup that we came up with and how it worked out for us.

The basic setup was as follows:

• Split the styles into their three components of the CSS make-up: layout, typography, skin (with the skin file containing the colour and graphics). As this kept things nicely compartmentalised and meant that we could re-use some styles from one site (e.g. the layout generally was the same for most content across all the sites) while applying extra changes specific to that site.
• The stylesheets were organised into directories based on the section (or sometimes specific page) of the application. So for example home/layout.css, home/skin.css, news/layout.css and news/skin.css etc.
• We could then also import specific stylesheets for each of our sites on top of these (both at a global and section level) which usually just overrode a few style declarations to keep these site-specific style rules to a minimum.
• All of this was managed server side using a configuration schema which knew where to look for the stylesheets for a given section of the application (as well as the global ones) and include them as appropriate for the given site.

We also had common comment styling for breaking the larger stylesheets into sections (which makes it easier to find things) and tried to alphabetise our properties within each style rule (although it’s not something that I personally could always stick to).

This was quite a good system, it may have looked complex based on the number of stylesheets that were imported for any given page but it worked out really well and we never really had any problems with our CSS system.

I’ve even used it on a few of my own larger side projects with minor tweaking to the system (e.g. dropping the configuration schema and following a Rails-like "Convention over Configuration" setup), and as I say it is very similar to the one described in the A List Apart article Progressive Enhancement with CSS — that has a really good idea for handling the different media types, which we handled via our schema.

Previously I’ve used query strings parameters within asset requests so that they act as a ‘cache bust’ parameter, these have usually been the source control revision number and is built into the release process. But I’ve never taken the step of force an expiry date on content that can be cached and the solution in the post is a lot more fine grained than my previous solutions. Something to consider for the future.

This was based on my personal experience and my personal preference – I think your average user appreciates being able to easily identify a text box, a form button etc. – as forms can be confronting beasts to some people. If you leave all the form controls in their default style in the users chosen browser then at least they can readily and quickly identify and understand them.

This is always something that the designer in me (and designers and other colleagues I work with) naturally (and usually subconsciously, on my part) fight. Quite often I end up styling form controls (buttons especially) in my design mock-ups and by that point it’s harder to let go of them.

I have in the past on numerous occasions thought "I wish that all browsers would allow me to do whatever I want with form controls" but that thought soon passed when I thought about some of the hideous monstrosities that would allow people to create, I’d never even contemplated the why and how it would be implemented by the browser or in CSS. Eric Meyer, on the other hand, has thought about it. It’s a very long post but defiantly a worthwhile read if this is something you’ve ever had to face.

One thing that has always bugged me is trying to get the base text size the same across all browsers, but now I've totally dropped the idea of supporting IE 5.5 ever again I thought it might be easier now.

After a bit of searching I didn't really come up with any "Eureka!" posts where someone said "This is the way to do it", but eventually I came across a short post which says that using one of the following 60, 69%, 76%, 83%, or 89% as the font-size on the body should work out pretty well cross-browser.

The lack of a comment thread and the slightly strange site I found this on led me to investigate it further. So I made a test file with the following:

With the following styles applied:

Then proceeded to do a bit of browser testing, and by god it works pretty much perfectly. I tested in IE 6, IE 7, Firefox 2 (PC & Mac), Opera 9 (PC & Mac), Safari 2 and Camino 1 and the results are very consistent.

Note: The important stuff where all the magic lives is those first 2 lines on the body selector the line-height stuff was my addition - I noticed that it appeared to be quite different on the PC compared to the Mac (in my tests anyway).

So I have to thank Carl Uebelhart for the slightly strange post that opened up this lovely simplistic CSS.

Again, if you're interested I have posted a slide show gallery of the results in all the browsers mentioned for reference.

Well this evening I came across the problem again, and found the solution - IE (I'm just looking at 6 here - not sure if 7 does the same) doesn't like it when you have a position: relative; on the child (or possibly children) of an element which you have declared overflow: hidden;.

So in my case swapping that out for position: absolute; on the child and overflow: hidden; position: relative; on the parent worked a charm. Now IE 6 plays nicely like its other browser friends.

While developing this prototype I only concentrated on making it work within Firefox, as that was our demonstration platform. Usually when developing, especially with XHTML and CSS, I can see the areas that will be a problem in other browsers and apply hacks at the time. Not having to do this made the entire development so much easier, I concentrated on developing with standards in mind and with Prototype & Script.aculo.us for the JavaScript I could be certain that the results in the browser were exactly what I intended when I refreshed.

At the end of the development when I was handing it over to the person who was to do the presentation I explained how much easier it was to not have to worry about hacking around to fix issues in certain browsers, at which point he asked what it would look like in Internet Explorer. I hadn't checked as there was no need to, so I fired it up out of curiosity and even I was shocked by the mangled results; everything was wrong, some parts were missing completely.

My friend remarked "I didn't know you had to do so much to make it work in IE" and that sad part was that neither did I, it had become second nature to me to spot the majority of these issues in the code and fix them as I'm going along.

Sure I know how to fix most of the issues that I saw in front of me, but I also know that some of the more major ones may have the potential to make me swear at the monitor for a couple of hours.

So I got a glimpse of the future purely by accident and I don't want to go back, I want that future to be now. From now on I would add the increased speed of development, flexibility and satisfaction (that you actually do know what you're doing when all these separate area of code are brought together in a browser and work exactly as expected) to any list of reasons to use web standards.

I look forward to a brighter future and only hope that it will be upon us soon.

At first it looked quite promising, but upon experimentation it proved, for me at least, to be a little bit hit and miss to get it right in all browsers, and I must admit I gave up trying to tweak the margins and paddings quite quickly. But I liked the idea of not having to resort to using images for the large quotes, as I have done on previous attempts and began adding my own thoughts to the mix.

As simon stated:

I must admit that the heights, margins and spacing don’t make a lot of sense if you analyze them. This was a real trial and error job. Get it working on Safari, and IE would fail. Sort IE, and Firefox would go weird.

My aim was to get the same effect, but with slightly clearer rules affecting the position of the quotation marks. My solution is not quite as clean as the original in the markup (added one span) and requires a little more CSS with some specific targeting of IE. However I believe that the CSS rules and their roles in my solution are clearer to understand and thus change to reproduce the effect accordingly.

For the eager among you check out the demo page for the final results, then read how I executed it.

First the markup:

The only addition here is the span before the closing quotation mark, which contains a single non-breaking space character.

The CSS

What this does is:

• For all browsers we are positioning the quotation mark span elements absolutely to the relatively positioned blockquote.
• For the opening quotation mark we fiddle with the top positioning value to ensure the quotation mark appears where we want.
• For the closing quotation mark we apply a negative top margin to make it appear in line with the text, note that this has the same value as the top positioning applied to the opening quotation mark.
• To ensure that the quotation marks don't appear over the text itself a text indent is applied, which is removed from the quotation marks themselves. This is the reason for the extra span, to create the space for the final quotation mark.

The only values that need tweaking, to account for the size of the quotes for your given font family or the chosen scale of the quotes themselves, are the text-indent, top positioning and negative margin (remember these two have the same value).

This is enough for all browsers except IE to which we have to apply some extra rules. These additions mean we end up with the following as our final CSS:

The absolute positioning method was producing widely different results on the opening quote in each version of IE on the PC, it even removed the text-indent in IE 5.5 - which re-appeared when the following solution was applied.

So I returned to Simon's solution to fix this. In this case as we're only dealing with one family of browsers, and thankfully the results are the same in all three versions of IE on the PC, we only have to apply values to the top and bottom margins for IE.

These IE specific rules are then over-ridden using the child selector, so every other browser gets the original CSS in the cascade.

The closing quotation mark was, thankfully, appearing in the same place in all three versions of IE and in pretty much the same place as every other browser, so it was simply a matter of increasing the size of the negative top margin, note that this is again the same value applied to the opening quotation mark. If you're not a perfectionist you could even get away with accounting for this tiny difference without loosing any sleep.

See the demo page for the final results.

Browser Support

Tested with:
PC : Firefox 1.5, Opera 8.5, NS 7.1, IE 5, 5.5, 6
Mac : Safari 2.0, Firefox 1.5

Notes:

• Firefox 1.5 on the Mac only the closing quotation mark overlaps the text where the last line is full width. This is because the text-indent is not been applied to the span that contains the   and I can't seem to make it apply it.
• In the demo when I added a background color the opening quotation mark disappeared in IE 5.5 and IE 6.0, this was solved by adding the ever useful IE CSS bug fixer known position: relative;.

I've not had chance to test it on a Mac yet, but when I do I'll post the results. Update: I've just tested on the Mac and have added the browsers above, I must also apologise to my Safari visitors as I noticed a bug with the code example areas - which I've now fixed.

Something a little weird is going on here for me, IE 5.0 is applying the rules within the child selector, I'm pretty sure that it shouldn't but can't explain why it is. Anyhow if this is a common occurrence the absolute positioning solution it ends up applying seems to work fine (go figure).

The design calls for the site to be a 760 x 420 pixel container centered both horizontally and vertically within the navigator.

As anyone who has tried this will know, vertically aligning block level elements in CSS is not the easiest thing to achieve. It's something I've done a couple of times, but the technique(s) to achieve this always escape me and I spend 10 minutes searching for the most concise and compatible method. Today that search brought me to a page on Centering elements on a CSS website.

It almost worked perfectly out of the box, apparently IE Mac doesn't like the negative vertical margin.

The solution I have, which relies on the the IE Mac CSS Filter to simply remove the negative vertical margin, is:

It is untested on IE Mac, but it should work. I understand the current discussions on the use of hacks especially those to do with fixing things in IE, but I'm not 100% convinced yet, I see them as necessary for IE 6 and below & IE Mac and I don't really like the kludginess of conditional comments, but I digress, it works for me.