Sunday, July 30, 2006

CSS Inheritance Rules

Web development has a number of technolgies that can be used to render a web page. Here's the most important one's for me:
  • HTML
  • CSS
  • Javascript and DHTML
  • Ajax (Using Javascript to make server requests and update portions of the page).
  • Some scripting language - JSP, XSLT, ASP.Net, PHP
  • Flash
CSS is a very important peice in this list of technologies to master, but one most front-end developers think is simple and one that can be ignored or cut-and-pasted. I have a couple interview questions that I ask about CSS and as yet, no one has been able to answer them correctly and confidently. Developers tend to "get by" with css. This is often true with javascript, too.

I mainly want to know if the interviewee knows how cascading works in CSS. Specifically, I ask:
"Can you give me the formula for determining how a style rule is applied to an element when there are multiple rules that could apply?"

Or in CSS vernacular -

"How do you calculate a selectors specificity?" The answer is here

This isn't critical to being hired, but understanding the algorithms used by browsers to handle rule conflicts in CSS will only help your web development and shows you have a handle on this area of web development. Of course, using CSS in a practical way requires a deeper knowledge of the actual declaration properties that can be applied to the HTML elements. This just comes with time and experience.

Tuesday, July 25, 2006

Reusing JSTL tags

We're using jsp and tag libraries pretty heavily in the enterprise application at Jobster. I had a chance to rewrite the application front-end code a few months ago, and came away with an infrastructure and architecture that is pretty nice for reusing components and 'widgets' on the front end.

For example, the list of jobs, and the list of prospects might have many similarities in HTML and CSS. Having these two pages use the same tag to render the parts that are similar is a win - reducing code, making it easier to maintain and update.

In our case, we have many lists (recruiters, prospects, contacts, employees, jobs, sources, messages to name a few) that have similarities.

I ended up with a mini-MVC architecture in the tag libraries. Where some tags took on Model properties, some took on Controller properties, and some acted more like Views.

The model type tags were needed to get the data in a very predictable consistent format. Lists of Maps was the preferred approach. If the data for one job list was slightly different than another job list, I used the model tags to convert and standardize. If I was handed a list of "Job" objects, I would convert to lists and maps.

The controller tags were application/use specific - they were used to combine the right data with the right view. For example, the recruiter list and the contact list are both lists of people, but they displayed different properties for each person in the list. The controller tag in this case accepts the data for the recruiter (a java.util.List object), calls the correct table row tag for each item in the list to generate the recruiter specific row, and passes these results to the view tag for final rendering.

The view tags are application agnostic. They accept strings and output them. This is a nice split, as the view tags can be reused easily. CSS becomes the only way to create different looks, the HTML is always consistent and predictable. There are view tags for the different parts of the page. Each is a wrapper that may include the results of another tag.

Most of my tags ended up being controller tags. Most of the changes occur in Layout tags. Code size reduced by 25%. Page weight reduced by 50%.

Once this infrastructure was in place, we were able to go through a complete redesign of 230 screens in the recruiter enterprise application - implementing a new brand in about 5 days (front-end coding). Most of modification occured in the wrapper view tags, and the CSS files. Past redesigns would take significantly longer.