Leave the Past Behind: Switch to CSS3
Join the DZone community and get the full member experience.Join For Free
after years of saying ‘what-if,’ 'some-day,’ and 'boy wouldn't that be nice,' pentaho has adopted css3 in its java web application. it took a major release ( pentaho bi 4 ) with a commitment to refresh our ui to adopt a more modern look. what the pentaho development team delivered is part apple ios and part windows 7: rounded corners; transparency effects; gradients; drop-shadows; text-shadows; and inner glows; all created with css3 while gracefully degrading for less-capable browsers. this single decision to adopt css3 made it possible to implement this new look in weeks instead of months.
a big leap to css3
personal desires aside, browser usage statistics and a bunch of other boring factors pushed our corporate decision to move to css3. suffice it to say, the time was right for us; the benefits of transitioning to css3 vs. continuing with the way we’d done things in the past suggested a huge advantage.
with our traditional approach, accomplishing this updated look would have required manual slicing of images and painstaking back-and-forth with developers, designers, and managers. a typical skinning exercise went something like this:
- designer creates mock-ups.
- designer presents mock-ups to programmer who promptly has a mild heart attack.
- programmer sits with designer to show exactly how everything should be sliced up.
- some time later, the designer delivers dozens (if not hundreds) of image slices.
- programmer was wrong about some areas, asks the designer for different slices.
- programmer then applies these images in the code, having to construct complex html and css to match the mockups.
that's one iteration, but come on, it's never done at one! the ceo's going to get his hands on a development build and change his mind (hi, richard!) -- “the whole thing needs to be lighter and less rounded.” more slicing. “that glassy effect needs to be a bit more opaque.” more slicing! and you’d better hope you have your image names and locations straight.
every time you go through this process, your willingness to make more adjustments approaches zero. that's the sort of compromise, born of pain, which really screams for new technology. thankfully, this old workflow was completely avoided by our adoption of css3.
the new theme for the pentaho bi 4 release, excluding icons, contains less than a dozen images. most of these are for small accent items like splitter grabbers and scrollbar arrows. no more slicing up photoshop mocks! it's for real.
since the vast majority of the new look was constructed by stylesheets, iterations among the graphic designer, programmer, and product owner were very short. this quick turnaround time was extremely valuable, allowing the kind of experimentation and real-life product use that mock-ups alone can never provide.
for instance, our first revision had a largely transparent button panel at the bottom of our dialogs. this looked great in the mock-ups, but in practice there was a huge problem: you can't control the position of centered dialogs when a user's resolution isn’t fixed. this led to buttons from behind the dialog lining up with the dialog button bar, which made them appear to be disabled dialog buttons! there's just no substitute for actual product use when you’re debugging a design.
put your html on a diet
abstracting the entire layout to css also allowed us trim down the size of our html files. this resulted in faster application load time and better performance. take a look at the tag soup for rounded buttons from our previous releases:
<table border="0" cellspacing="0" cellpadding="0" class="roundedbutton" id="okbutton"> <tbody> <tr> <td align="left" style="vertical-align: top"> </td> <td class="roundedbutton-slice" align="left" style="vertical-align: top"> <div class="roundedbutton-label roundedbutton-label-label">open</div> </td> <td align="left" style="vertical-align: top"> </td> </tr> </tbody> </table>
and now here's the code for the new button:
it looks much better when rendered, too:
our tab panel has gone from over fifty lines of nested tables to ten lines of divs and spans. it's been my team’s collective development experience on this and other projects that the less table structure a browser has to deal with, the faster the page will feel to a user. in a complex application like our user console (which mimics the feel of a desktop application), the combined reduction in html has a large positive impact on browser responsiveness. we're not even close to trimming out all that we can, but at least now we have the ability to do it.
alpha gradients with rgba
we're also making heavy use of the ability of modern browsers have partially transparent colors (rgba). the new default theme for pentaho bi 4 is highly transparent or "glassy." this look allows administrators to easily change the feel of the interface by changing the background image underneath. take a look at the following screenshots. both are using the same theme, but with a different background. i think you'll agree the results are compelling:
with new background:
dealing with the down-side
of course, there's a flip-side to every coin, and all was not completely rosy during development. that scourge of web development -- internet explorer -- threw a wrench in our plans, and as usual, ie compatibility was an exercise in compromise. even taking ie6 completely out of consideration, there were still problems. we first had to accept the lack of rounded corners with ie 7 and 8. gradients and partially transparent elements which were at first constructed with activex filters had to be replaced with image slices. cleartype fonts look terrible on top of filtered elements; thankfully, though, ie9 supports some of the css3 styles, most notably rgba and border-radius.
another area of compromise was with style duplication. while we've taken great care to avoid it where possible, in some instances we had no choice due to css3's lack of inheritance. it would be impossible to combine "drop-shadow" and "inner-glow" classes as they're both defined with the "background" property; the last one defined will win. this leads to classes with names like "drop-shadow-w-inner-glow," where the styles from the two are duplicated and combined.
there are some server-side solutions to the inheritance problem which add a meta-layer on top of css and output the calculated results. we may investigate these at a later point; in addition to providing inheritance, they can output browser-specific stylesheets free of hacks and the namespacing we're using today. another benefit of this server-side processing is that we could perform neat tricks like increasing the contrast and shifting the hues of the color palette on the fly.
is it time for you to switch to css3?
if your project hasn't upgraded to css3, i highly encourage you to analyze your usage statics and make the move if you can. the benefits to us were: faster implementation, quicker (and therefore more frequent and productive) iterations, better browser performance, and reduced cost. any negative factors we thought of couldn’t outweigh these. that mythical “someday” has finally arrived , and it feels great to look back on.
nick baker is a lead programmer for the world leader in open source business intelligence, pentaho corporation. he has over 12 years experience as a java and web developer with expertise on using cutting-edge technologies to deliver compelling user interfaces.
Opinions expressed by DZone contributors are their own.