Browser Specific CSS

Browser Specific CSS
Most of time we spend time in fixing the style issues to make the web page work in all the browsers, particulary IE browsers. In this post we look at how to include the css file for browser version. This will also go in tag with all the regular css links. The opening and closing tags should be inside the HTML comments. Between the comments targeted browser is specified as below:

Target ALL Versions of IE:

<!--[if IE]>

<link rel="stylesheet" type="text/css" href="ie_only.css”>

<![endif]-->

Target ALL browsers except IE:

<!--[if !IE] >

<link rel="stylesheet" type="text/css" href="not_ie_only.css”>

<![endif]-->

Target IE 7 only:

<!--[if IE 7] >

<link rel="stylesheet" type="text/css" href="ie_7_only.css”>

<![endif]-->

Target IE 6 only:

<!--[if IE 6] >

<link rel="stylesheet" type="text/css" href="ie_6_only.css”>

<![endif]-->

Most of the time is good to include media="screen, projection" while targeting only IE 6 browsers.

Target IE 5 only:

<!--[if IE 5] >

<link rel="stylesheet" type="text/css" href="ie_5_only.css”>

<![endif]-->

Target IE 5.5:

<!--[if IE 5.5] >

<link rel="stylesheet" type="text/css" href="ie_5.5_only.css”>

<![endif]-->

Target IE 6 and lower versions:

<!--[if lt IE 7] >

<link rel="stylesheet" type="text/css" href="less_than_ie_6_only.css”>

<![endif]-->

Target IE 7 and higher version:

<!--[if gt IE 7] >

<link rel="stylesheet" type="text/css" href="greater_than_ie_7_only.css”>

<![endif]-->

gte (greater than equal), lte (less than equal) can also be used inside the HTML comments for including browser specific css file.

Elango

CSS Sprites

CSS Sprites
Almost all the web sites which we develop will have some basic functionality like, e-mail, print, rss feed, logo, etc.. And usually these will be provided as a image link to the user. Obviously we will be referring to separate image for each link. And we know for each asset, whether it is a image or css the browser makes a separate call to web server to get the information. Since we have separate image for each functionality the number of hops increases.

Till now I have also did the same thing :) , i.e. by including separate image for each one. After knowing about CSS Sprites I was more inclined towards it.

Below is the sample data shows the actual time taken by the HTML markup when compared to other files that supports the HTML formation:

Source: css-tricks.com

As given most of the time browser spends to get the supporting files like images. Consider if we have single image which all the images contained in it. Then the browser just needs to download just a single image which can be served to all. This reduces number of hops dramatically and your performance of the application will increase. This technique of combining the smaller images into single large image (not very large) is called CSS Sprites.

As a contrary many will believe that having single large image file will increase the size of the image file which will have impact on the performance again. But, here is the comparison:

I tested with an simple web application where I had ten small icons, for which

1) Having individual image took:

Number of HTTP Requests: 10

Total Size of the Images downloaded: 12.3 kb

2) Having a single image file using CSS Sprite concept

Number of HTTP Requests: 1

Total Size of the Images downloaded: 7.62 kb

Image File can be created using : http://www.csssprites.com/

Here I am taking about a simple web application, consider large applications where we usually have plenty of images being used. In those scenario CSS Sprite will be very handy.

I thought of sharing this info to every one. For more details about CSS Sprite, use the below links:

Reference:

1. http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/
2. http://css-tricks.com/css-sprites/
3. http://www.csssprites.com/

Regards,
Elango

Reading Properties file using ResourceBundle - native2ascii ANT task

Introduction
Most of the portlets or any web application that we usually create, will make use of the properties file to read and display the localized contents/value present in it. The .properties file created will be of encoding type ASCII. And as we know, for displaying the japenese and other language it should be of UTF-8 characters. Even if the properties files are stored as UTF-8 encoding type, still the content displayed for some of the languages would be junk. The reason being when the properties file is read using resource bundle object it doesn't know whether the characters are of UTF-8 format. There should be mechanism to make this properties file available for the web application.

We spent almost two to figure out this, hope this solves some time for you :)

Below are the steps that should be followed to make your web application to display the locale specific text:

Reading Properties file using Resource Bundle
a) Creating a proper properties file
First step would be to create a properties file with the encoding type UTF-8 format for all the locales. Inside the properties file have the locale specific text. eg. for japenese properties file,

portal.message=ポータル

Eventhough locale specific text is available for the web application to use it, the JVM treats all the contents as similar format. So option is to change the JVM settings to allow the UTF-8 characters. The other option would be to convert the existing UTF-8 characters into UNICODE characters so that it can be displayed normally.

But the problem is to have the unicode value in the properties file. It is hard to maintain and also not human readable. eg. the UNICODE value would be:

portal.message=&#12509;&#12540;&#12479;&#12523;

So there needs a mechanism to convert the UTF-8 characters to UNICODE at runtime or at compile time. And mostly we use ANT as the tool to build our projects to create the war file. So the idea should be implemented at the build level so that even the properties file can be human readable and also understood by underlying JVM.

b) Using native2ascii ANT task
Fortunately ANT provides option to use the native2ascii utility.

native2ascii: Converts files from native encodings to ASCII with escaped Unicode. A common usage is to convert source files maintained in a native operating systenm encoding to ASCII prior to compilation.

The option would be is to convert the properties file using the native2ascii utility so that the properties file entries will be converted to Unicode format. The Unicode format can be easliy be understood by any Operating system.

Sample ANT code for this is given below:

<!-- converting the properties file values to unicoce character values-->

<native2ascii encoding="UTF-8" src="${portletmodulename}/src" dest="${warfiledir}/WEB-INF/classes" includes="**/*.properties"/>

This convert all the UTF-8 characters into Unicode format at the build, so that even the web apps can use it. And also properties stored in the filesystem will be UTF-8 characters which is easily maintainable.

Reference:

http://ant.apache.org/manual/OptionalTasks/native2ascii.html

Regards,
Elango

Removing Unwanted spaces between the portlets

Introduction
One common problem which the portal developer come accross is the spacing issue that is formed between the portlets. Even though we develop themes and skins properly, the space between the portlets will still be exisiting. And in most of the scenario we want that to be controlled.

Here are few steps that needs to be followed to avoid the spaces between the portlets.

Removing Unwanted Spaces between the Portlets
a) Changing the default Skin for the themes
The custom theme or the exisiting portal theme which is applied to the portal page will have the default skin. To remove the unwanted spaces which is occuring between the portlets, first the default skin needs to be changed to "IBM No Skin" which does not contain any drag and drop feature code.

b) Modifying the applied Skin
The Skin which is applied to the page has to be modified to remove the unwanted spaces. All the javascript code related to drag and drop should be removed from skin. If "IBM No Skin" is used for the portlet then this step is not needed, as it is by default will not contain any drag and drop related code.

The above changes will remove all the extra spaces between the portlets.

Drawbacks:
Even using the above changes we get rid of the extra spaces, we are also losing the drag and drop feature. The places where drag and drop needs to be implemented, the above approach can't be used. Till WPS6.1 i believe this is the only way where you can remove the spaces between the portlets.

Regards,
Elango

Using TCP monitor in WPS

TCP Monitor:

You can use the TCP monitor which does exist in portal server itself. if you have installed portal server then you can use it using the following ways:

a) Open the cmd prompt, and navigate to AppServer\bin folder

> cd C:\IBM\WebSphere\AppServer\bin\

b) Execute the following command to open the tcp monitor:

C:\IBM\WebSphere\AppServer\bin> java -Djava.ext.dirs=C:\IBM\WebSphere\AppServer\runtimes\ com.ibm.ws.webservices.engine.utils.tcpmon

{give the runtimes path accordingly}

The tcp monitor should have opened by now. For more details: http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/twbs_tracewbs.html

Regards,

Elango