Home Contact
Validate the HTML of this page

Tomcat WebVoyáge

(An Alternate Approach to)
WebVoyáge CSS Customization

"In theory, theory and practice are the same. In practice, they are not."

We've got the power

We've just upgraded to Voyager 7.0 (or downloaded the preview server). The new architecture gives us the power and flexibility to customize WebVoyáge to our heart's content with CSS and XSL.

Let's think ahead

Before we get started though, a quick count tells us that an as-distributed skin has 46 CSS files. If we only had to customize them once, that wouldn't be a big deal.

But consider that each subsequent Voyager upgrade1 will bring a new set of CSS files. These new files may (or may not) contain changes from the previous versions. From a best practices standpoint, we would need to reconcile any customized CSS files with the new CSS files distributed in the upgrade.

And what about multiple skins? Consider the case of a site that implements 3 skins and customizes all 46 CSS files in each skin. They might be able to get away with just copying their customized CSS files back in place after the upgrade; but chances are that eventually there will be some changes in the new CSS files that have to be incorporated. 3 x 46 = 138 CSS files to reconcile. Ouch!

A more efficient way?

What if we only had to customize (and worry about) one CSS file per skin? In theory, we can by...

What does that accomplish? Due to the cascading nature of Cascading Style Sheets, rather than customizing by directly editing the as-distributed CSS files, we can customize by overriding (as needed) the configuration in the as-distributed CSS files.

Theory vs. practice

Will this work as described? In all likelihood, it won't be quite that simple. However it's an approach worth considering and I'd like to try it here at UT Arlington.


  1. Patchset upgrades (i.e. minor upgrade versions) will likely not entail new CSS files. However regular upgrades probably will. This is all conjecture on my part, since we really don't know yet.