Easing Project Development with CSS

A while back, I wrote a short bit on the benefits of CSS. Based on some recent debates within the JavaServerFaces community, I'm not sure developers fully understand what CSS can bring to the table of web applications. CSS isn't simply a new way of marking up HTML, but a new paradigm in web page development.

For those with A.D.D., click here to jump right to the summary. As a proof of concept, click here to see a sample project I'm currently working on.

Structure vs. Presentation

Let's first start by talking about development roles and concerns. MVC has taught us how to seperate our application into managable layers. We have the Model and Controller which are under the programmer's ownership, then we have the View which is under both the programmer's and designer's ownership. This is where issues arise as both the programmer and the designer wish to implement their concerns in the cleanest way possible within the same document or page.

Your programmers' concerns are to provide structure and data to web pages; really they shouldn't care how the data is presented, only that it's there and functions within the application requirements. The designers' concerns are to properly present information in a meaningful manner and should not concern themselves with knowing any server technologies such as tag libraries or the application's Java model.

How is this possible? By seperating structure and presentation with a proper CSS strategy. The end result is you have a base template for all JSP pages that is made up of a few <div> tags where the programmers can play freely, and the designers have free roam of CSS styles via external Style Sheet files. In order to give you a head start on your next project, I will outline a simple, agile strategy to use.

Gather Your Requirements

This phase is familiar to most, but we are only focusing on content at this point. The goal is to gain full knowledge of the amount of information your page structure will have to handle. One of the biggest mistakes designers can make is laying out a page structure without fully understanding the all of the content requirements. Programmers are used to these processes and can easily apply them to web design.

In a brain storming session write each content requirement on a notecard. These requirements can support any part of the application, such as: display global navigation, show order total, display validation errors, and show current login name. The next step is to group the requirements based on the following:

• Requirements common to all pages. These requirements categorically occur only once on a page.


• Requirements specific to a single page or section of the web site. These requirements or similar ones could show up multiple times on a single page.

Common Content Requirements

This is simple enough as most sites have common content requirements such as displaying the global navigation or showing the company's logo. These common requirements to all pages will be use to define your JSP template's structure in <div> elements. The <div> elements don't necessarily have to match up to specific requirements, but think of them as mapping behavior to object hierarchies. An example would be:

<div id="page">
    <div id="header"/>
    <div id="navigation"/>
    <div id="subnavigation"/>
    <div id="content"/>
    <div id="sidebar"/>
    <div id="footer"/>
</div>

Notice that we are using id's on the structual <div> elements. Since these elements will be common to all pages, designers can identify these one and only elements within their CSS files to support the layout.

It is very important to get designers' input in defining the common page structure. As a programmer, you are only concerned about being able to categorize your data within that structure. The designer will still need to be able to present that structure in a meaningful way with CSS. Undoubtedly, the designer will already have some layout ideas and will want to add or move <div> elements around. Some of the elements the designer may want to add will only act as "hooks" for laying out content (think of them as template methods). This is okay since we are simply decorating while preserving the original structure. The less elements, the better.

<div id="page">
    <div id="header"/>
    <div id="navigation"/>
    <div id="subnavigation"/>
    <div id="content-layout">
        <div id="content"/>
    </div>
    <div id="sidebar-layout"/>
        <div id="sidebar"/>
    </div>
    <div id="footer"/>
</div>

In the above example, we've added hooks for laying out the content and side bar content. The reasons for doing so are beyond the scope of this article, but serve as an example of what should happen to the structure.

Context Specific Content Requirements

You should now think about the second notecard pile of requirements which were specific to some context or page. We will take this pile and categorize it further with the help of the designers.

In reality, we have two different kinds of requirements left, content requirements for a few pages or section, and content requirements specific to a single page. The reason for working with both sub-types of requirements is that we need to now categorize all these requirements within the page structure previously created. These requirements could be anything from displaying validation errors to showing related links. The designers will start to prioritize/categorize these requirements as members of the "content" or "sidebar" <div> elements.

Previously, we labeled our common structual requirements with id's as they were first class members of the page and common to all pages: banner, footer, and content. These other, context specific, requirements could theoretically be replicated multiple times on the same page, such as displaying related links or displaying an order's status. In terms of design, these would show up as boxes within the side bar. Since these elements show up multiple times in a page, we specify them as CSS classes. We don't necessarily care how they are decorated at this point, only that we can categorize these requirements and label them at this point.

<div id="sidebar">
    <div class="sidebox">Order Status</div>
    <div class="sidebox">Related Links</div>
</div>

There are exceptions to the above statement, but the general rule is: use id's if there can only be one structual occurance of an element on a page, otherwise define a class that can be used multiple times for content categorization. You would be free to use an id to label your <div> for validation messages if it could only show up once on a single page.

Mocking Up the Presentation

At this point, the programmers should feel free to go work on their models and persistence layers. The designer should now formulate a proof of concept for the view layer by mocking up the presentation layer in straight XHTML. Since the designers usually know XHTML better than the programmers, these mocks will also serve as examples to the programmers to work from.

Page mocks should be used and modified throughout the development cycle as a static version of the dynamic pages the programmers will create. Designers can easily work with styles on their local drives and present changes to the client without worrying about any server-side technology.

Programmer Page Development

By now you should have a pretty good feel for the structure of the web pages. We have also been able to define rules for the programmers with the help of the designers. An example rule would be that the current sub navigation goes in a <div> element with an id equal to "subnavigation".

<div id="subnavigation">
    <ul>
        <li><a>Employee Search</a></li>
        <li><a>Add Employee</a></li>
        <li id="current"><a>Employee Reports</a></li>
    </ul>
</div>

Notice we label the currently selected navigation item with an id of "current". Since only one navigation element can be selected, we use an id instead of class. We aren't defining any formatting in the above example, simply labeling the structure for decoration by CSS. I'm sure we've all written <c:if> statements to determine if we want to wrap some content in a font tag-- a very poor practice. By relying on CSS, the page structure is declarative and is not intermingled with presentation logic.

By not intermingling presentation logic with the structure, maintenance is much easier. No longer do you have to worry about scrolling inside of tables within tables within rows to find out where some content should be added. Additional development tools will help isolate changes.

The Tools of the Trade

The programmer and the designer each have their preferred tools. You can't expect a designer to be as efficient in Eclipse as they are working with Macromedia Dreamweaver. Since you've initially defined the page structures, I recommend having the designers create Dreamweaver templates for the programmers to use. This serves the purpose of isolating changes in the case where a designer and programmer need to modify the same page or some sub set of pages such as all of the "article" pages.

At the same time, Dreamweaver or not, we've really taken out the need to educate the designers on your application models or tags. It's not their responsibility to deal with how the content gets into the page, only how it's presented. Again, the programmer just needs to make sure that their CSS id's and classes are rendered with their content.

JavaServerFaces

Just like we grouped our 'componentized' our page structure, JavaServerFaces offers components that serve the programmer's data models. A <c:forEach> tag with a twenty or so table-related XHTML tags can now be replaced with a single <h:dataTable> tag for rendering collections of data. The best part is that the specification also 'enforces' the use of CSS via various style attributes on the tag, allowing you to delegate the style to a seperate CSS file.

Even though JavaServerFaces comes with a small set of components, I recommend creating new ones or finding new ones where ever possible. These components can be used in place of importing other JSP pages, such as a menu component or an order basket component that programmers can place on their pages. Again, we are isolating the same kind of changes you have gotten from doing JSP includes.

The basic idea is that you want to stay away from "respecifying" data structures within the page. Behavior such as sorting, filtering, and pagination can be isolated within a custom component and dropped into a page with a single JSP tag.

In reference to the tools of the trade section above, Sun has a great product out called Java Studio Creator for working with JavaServerFaces. Not only do you have drag and drop capabilities for rapid application development, but all styles and presentation are specified via CSS, allowing you to easily use a web designer's external style sheet. Awesome stuff.

Summary of Benefits

Since we've been able to clearly define our structual page "framework" in XHTML elements, lets talk about some of the develpment benefits.

• Development is now asynchronous between the designer and the programmer. As long as the programmer sticks to the agreed upon structure, the designer is free to modify the look and feel of the site at any time without touching the programmer's work.


• Ideal for environments with micro-managment. Even after the site has been pushed to production, web designers can easily change fonts and graphics in seperate CSS files. Theoretically, you could give your site a whole new look without modifying any pages, only the CSS files.


• Page structure is much easier to maintain when it isn't intermingled with presentation glitz, such as layout tables.


• Use id's to label structures that are unique to the page (only one possible occurance) and use classes to label structures that are reoccuring on a single page or slightly different across multiple pages.


• Use Dreamweaver MX to template pages. Templating technologies such as Sitemesh and Tiles serve the programmer and don't really do anything for the web designer. The designers have ownership of Dreamweaver templates and can easily reflect changes in programmer's JSP pages without modifying their content in any way.


• Use Sun's Studio Creator to rapidly develop web applications. Studio Creator generates code that has a clean seperation of structure and presentation with CSS. Programmers can create functioning applications quickly and later replace the default styles with those provided by the web designer's CSS files.


• CSS is quite capable and nay-sayers should spend some time reading and exploring actual examples of CSS design. Mainstream sites such as Yahoo, ABC News, Mapquest, Sprint, FastCompany, and ESPN are all going to a strict XHTML/CSS format.


• Using CSS media attributes, a single page from a programmer can serve screens, print, and handhelds at once.

I have to admit that taking this approach may initially slow development as employees spend time educating themselves. But from a pure maintainability and flexability aspect, I can't think of a better way to do web pages today.