In the "ice:outputStyle" taglib documentation it indicates that the filename contained
in the 'href="file.css"' parameter will also attempt to deliver a browser-specific version of the CSS file
if the browser-specific file is found, and the "file.css" if not. 

Icefaces uses the User-Agent header in the request to determine what browser-specific CSS file to deliver.

Browser-specific CSS files look like "file_ie7.css" or "file_ie8.css".

The way this delivery is accomplished in the original code is by appending a new "link" tag to the existing one, so there are then
two links seen in the source, one for the original file and one for the new browser-specific (e.g. "..._ie8.css") one.

In the example application we have two CSS files, and each of their browser-specific counterparts existing in the "css" directory:

	css/test1.css
	css/test1_ie7.css
	css/test1_ie8.css
	css/test2.css
	css/test2_ie7.css
	css/test2_ie8.css
	
When  "ice:outputStyle" tags are provided for both css/test1.css and css/test2.css, we should see four <link> tags like this:

	<link href="css/test1.css" rel="stylesheet" type="text/css" />
	<link href="css/test1_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
	<link href="css/test2.css" rel="stylesheet" type="text/css" />
	<link href="css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />

Unfortunately, sometimes this doesn't work. 

In particular, if an absolute path starting with "/" is used in the "href" attribute, or if a relative path starting with ".." 
is used, IceFaces OutputStyleRenderer code looks in the wrong place to determine if the browser-specific version of
the file exists.

To that end, we have created our own "medice:outputStyle" tag, which does provide the correct link tag in all valid circumstances.
This tag is back by code that extends the original icefaces tag code.
 
	
In the example application, we have four basic use cases:

	Absolute path, top directory
	Absolute path, child directory
	Relative path, top directory
	Relative path, child directory

Each of these uses cases are covered in a separate page. Each one of the pages has one invokation of the "ice:outputStyle" and
one invokation of our version of the "ice:outputStyle" tag - "medice:outputStyle". 

All through the examples, the "ice" version of the tag tries to deliver test1.css, and the "medice" version tries to deliver test2.css.

In this back-to-back scenario, we can easily see that all valid paths work for the "medice" version, but some do not work for the 
original "ice" version of the tag. For example in the "relative/child" scenario for IE8, we should see:

	<link href="../css/test1.css" rel="stylesheet" type="text/css" />
	<link href="../css/test1_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
	<link href="../css/test2.css" rel="stylesheet" type="text/css" />
	<link href="../css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />

Instead, viewing the source, we see:

	<link href="../css/test1.css" rel="stylesheet" type="text/css" />
	<link href="../css/test2.css" rel="stylesheet" type="text/css" />
	<link href="../css/test2_ie8.css" rel="stylesheet" title="_ie8" type="text/css" />
	
The "test1" css that is generated by the "ice" version of the tag, doesn't have the browser-specific link appended. That link tag is missing.
This is incorrect. The "medice" version correctly delivers both in this case.

The only use-case that works correctly is "relative/top".

You want to look at our com.med.icefaces.style.OutputStyleRenderer.encodeEnd(...) method in the sample app. 

In it you will find that for the various use-cases, our custom extension of the Icefaces OutputStyleRenderer class searches 
for the real browser-specific file on the filesystem in the proper places based on the input "href" path supplied. In some cases,
it will need to detect if the href starts with the context-root, and strip it off, so that the getRealPath can get the real path
of the file, to determine if it really does exist.