Here I want to share some of my experiences( pains I went through ) while developing styles for my previous projects. One of the project is based on div structure and other is based on table and div structure.

Some CSS styling attributes differs from browser to browser. But when we are developing a website most of the clients want their site to be compatible for all browsers. By cross browser compatible CSS it doesn’t mean that website works in all browsers, it also should have same look n feel in all browsers.

CSS validation
When ever you found some difference in the appearance of page in different browsers, validate the css file. Check for syntax errors in the file eg. missing, closing or extra braces while defining styles. Suppose I have defined a style for a div as follows

 div#wrongStyle{{
   color : red;
   font-size:19px;
 }

IE applies above styles to the div but not Firefox. IE can correct such small errors but Firefox wont do that.
Separating styles
If you want to provide styling based on IE version you can use specify it in the following manner.

Developing styles for DIV based structure

In div based structure each element on the web page is placed inside a div and styles will be applied to it. To position those div elements you can use absolute positioning with fixed width or relative positioning.

Here the first thing we need to keep in mind is to separate positioning information from styling information. So that common styles like font, colors can be specified in top elements. It helps to maintain the layout without disturbing the styles. While developing these styles ,its a good idea to go in agile manner. i.e after applying each element check the page in all target browsers. This eases fixing the cross browser issues. If you are using absolute positioning you can develop each element in separate html file. These separate files or absolutely positioned div elements can be merged easily to form a complete web page.

CSS width, padding problem

The box model hack is used to fix a rendering problem in pre-IE 6 browsers, where by the border and padding are included in the width of an element, as opposed to added on.
For example, when specifying the dimensions of a container you might use the following CSS rule:

 #box
 {
      width: 100px;
      border: 5px;
      padding: 20px;
  }

This CSS rule would be applied to:

    This is some dummy division holding a dummy text

In normal browsers above rule is interpreted as 100px width + two 5px borders + two 20px paddings. So the final width of the element will be
150px. But in pre-IE6 browsers the total width would be just 100px, with the padding and border widths being incorporated into this width.

A simple way to solve this is to have one more div inside and specify width for inner one and padding and margin to the outer. The code will look like…

#box
{
 width: 150px;
}
#boxInner
{
border: 5px;
padding: 20px;
}

And the new HTML would be:

               This is some dummy division holding dummy text
     

Using the above code will help to show the box width to 150px regardless of the browser.

Selecting precise descendants

Sometimes CSS selectors also behaves differently in different browsers. To apply styles to a particular element in the page you can use child selector ( ” parent > child > child’s child ” ). In my case, I faced the following problem. I need to apply some style only to the first li under “parent” class ul element and I don’t have any control over the html code.

 Item 1

 Sub Item 1 
 Sub Item 1 


Item 2 

Now, you can specify the styling in the following way using child selector parent > li { style goes here}. There might be some other way for this. But I found it the above way useful as I can’t change the html code.

Using Table structure for page

The most important thing we need to keep in mind while developing styles for tables is, on the top level element (usually body) specify padding, margin and border to be 0px. After that you can specify these attributes individually by assigning the div id or class where ever required. Also specify “cellpadding”, “cellspacing” and “border” values in table tag explicitly, because the default values for these attributes differs from browser to browser.

Conclusion

You can find many other tips like this on net. Its always better to restructure our css and layout to make styling compatible with different browser rather than using some hacks. If you are using some hack it might work in the browser that you are testing and might not work on end user browser . These are the ones that I have found useful during part of my projects development You can also share your experiences ( or pains ) here while using CSS.

In this article I am going to share some of my experiences with my first project. This is an agile project based on a technology which is new to the whole team. I spent around two weeks in understanding the technical features and strengths of the technology.Where as others in the team had never worked with it or similar technology. Here I will discuss about some mistakes that ( I feel )we did while executing the project.

Most of the things discussed here might even apply to those projects ,where part of the team is new to the technologies selected for the project. The risk factor is lower in projects, that has atleast one team member who already knows the ins and outs of the technology selected for the project.The following things should be taken care of when whole or most part of the agile team are working on a completely new technology.

First and most important step is to evaluate the technology for the given project requirements. Doing the evaluation gives the team a motivation to learn if it’s really worth. Developer at some point may get a feeling that why should they use this technology instead some thing that he/she already know.
This kind of feeling on the minds of developers affects their learning skills and inturn productivity. Although the technology chosen may not be the best, evaluating it definitely gives the developer a psychological boost to learn and appreciate the use of it for the project.Do this evaluation until the whole team feels that this chosen technology definitely provides some value for the project.Being agile we can give the team room to change the technology in middle. But at that times we need to think about cost involved in chaging the technology of choice.

Once every one gets a good understanding about the technology, collect full documentation and any other training information for that particular technology and make it accessible for team members. Instead of directly starting with development work , first let the team to explore technology. They should get a overview of technology like what are the features it provides , playing with some sample codes. But there is no need to learn or master the technology at beginning itself. If it is a big project, its better to have a beginners-course for all to learn the new technology.

Once the team gets the overview ,team members can start with development. While working on different tasks people comes across different new features ,problems and solutions for them. So it is better share the knowledge among the team during the standup or iteration planning. This makes others need not waste their time on issues on which some one already explored. This knowledge transfer can be done easily in agile process by changing pairs frequently. It can also be done by having knowledge transfer meetings at regular periods, may be once or twice in a week. Some times when the problem is major it can be on-demand.

Another most important thing is, we should be careful while choosing iteration backlog. When chosing the task, expect the worst case. This is because team dont know the actual complexity of the task.If by mistake the task take more time than expected, it will give a bad impression to the client. Especially in agile projects where client satisfaction is very important , estimation of complexity points plays a crucial role here.

Dont believe in burndown chart. Burndown chart shows the progress of what has been done already. We cant make estimations based on current velocity as we dont know what type of path is ahead to us. So in both of the above situations , its better to do a risk analysis and adjust the time needed for tasks using risk factor calculated. Spike testing also can help in estimating the effort needed with more accuracy.

The most common problem in agile projects is lack of continuos feedback from stakeholders. This is can be too dangerous as in this case: at every instance whenever there is no stakeholders feedback, team takes its own decision and proceedes in that direction. By the time team gets the feedback they have to again spend the same or more amount of effort for fixing things. Some times it might be worst and gives a feeling to everyone that project is a failure.

Although there are problems with agile based projects based on new technologies, it may still suite such projects if proper care is taken. With agile we can fail early to judge the technology of choice. We can see the working software at the end of each iteration which gives confidence to developers and client about technology. The feedback mechanism in agile guides developers to go in right direction. If we can take into account the above discussed problems , agile can make these projects successful. I would be interested to hear your comments and experiences with such projects as well.