We’re really not asking a lot. In fact we want to save them time and money in the long run. Microsoft needs to learn that it doesn’t need to do everything itself and open source projects such as Mozilla and WebKit are there for the taking. They just need to pick them up and they’re ready to go. What puzzles me about it all is it’s not a difficult thing for Microsoft to adopt one of these browser engines and build on them. They’re already more secure then IE will ever be, they work with WC3 standards and they don’t need to spend their money on developing something that seems like it will never actually be competitive with other browsers. They have the oldest and slowest browser on the market. See the results below from Peacekeeper.

They’re pretty dismal results, clearly the browser has passed it’s use by. There has been call outs everywhere for Microsoft to adopt one of the many browser engines yet they just flat out refuse to do it.

Internet Explorer is not the only product that they’re refusing to make web developer/user friendly and follow the standards. Outlook does not fully support CSS. Anyone who has ever made a HTML campaign with CSS will know how impossible it is to format and do the simplest thing without it looking like scrambled eggs in recent versions of Outlook. This inspired the wonderful fixoutlook.org. Back in 2000 they supported HTML now they’re using some terrible Word engine and for what? Here’s where I’m coming from, at what point do WORD and HTML even meet up. It doesn’t make sense. Why would you use a Word processor to render HTML? I don’t think this needs an explanation at all. It’s pretty straight forward, render HTML with a browser style engine, that’s what they’re built for.

So they say they’re listening, but I’m not sure that they are. The letter on this link doesn’t make sense. It shouldn’t even be a hard decision, support HTML, support standards. They’re there for a reason.

Feel free to have your say, I just wanted to share my opinion.

If you use the prototype javascript framework there is a call built in! Handy…

Here’s the code for Prototype users:

var pos = $("elementID").viewportOffset();
var x = pos[0];
var y = pos[1];

Nice and easy…

For those of you who don’t use prototype, below is a function you can use to get the X & Y coordinates relative to the page (viewport).

The Function:

function viewportOffset(forElement) {
	var valueT = 0, valueL = 0;<
	var element = document.getElementById(forElement);
	do {
		valueT += element.offsetTop  || 0;
		valueL += element.offsetLeft || 0;
		if (element.offsetParent == document.body) break;
	} while (element = element.offsetParent);
	element = forElement;
	do {
		if (element.tagName == 'BODY') {
			valueT -= element.scrollTop  || 0;
			valueL -= element.scrollLeft || 0;
		}
	} while (element = element.parentNode);
	return [valueL, valueT];
}

This is a modified function from the prototype framework.

Calling The Function:

var pos = viewportOffset("elementID");
var x = pos[0];
var y = pos[1];

I tried several of the functions on various blogs etc none of them seemed to return anything but 0 in Safari. The above has been tested and works in the latest versions Safari, Firefox, IE and Opera.

Enjoy!

The CSS I was using looks similar to this:

filter: alpha(opacity=50);

With Internet Explorer your opacity range goes from 0-100, so 50 should set the opacity to 50%. Of course it didn’t.

The Solution:

After hours of pulling out my hair, the problem was simply that the div didn’t have a width specified. The problem appears to be in all versions of Internet Explorer, even in IE8 beta. So if you’re having the same problem just specify a width for the element you are applying the transparency/opacity to and it should once again apply the transparency correctly.

The Solution

All you need to do is in your CSS is set the overflow as hidden.

overflow: hidden;

Here’s an inline example.

<div style="width:100%; height:1px; overflow:hidden; background-color:#000;"></div>

So why won’t Internet Explorer let it go less then 12px without this?

When you make a div in IE it will automatically stretch to the size of the content and not the height that you’ve set in your CSS. In typical IE fashion, it will always think there is text inside the div even when there isn’t, thus forcing the div to fit the size font you have set. Telling it to hide the overflow will then tell it “we don’t care if it goes over, just hide it!” fixing our problem. You can also change the font-size to smaller which IE will then allow the div to shrink to the height of the smaller font-size you’ve set. The overflow option is probably better, but both will do the trick. Now we have solved another Internet Explorer problem… There’s still more to come, so keep a look out!

Before Fix

After Fix

The Cure:

Add the following to your CSS style sheet.

img {
	display: block;
}

That will automatically apply the correct styling to all your images.

NOTE: You can not have images side by side with this styling, they will automatically drop underneath each other. If you need them side by side you can do so by putting it in a table or using CSS.

If you only want to apply the style to some images you can add the following to your image tags.

style="display:block;"

This will apply the style to the image who’s tag you have placed it in.

So why does Internet Explorer put the gap there in the first place?

Well IE sets the default display as “inline” which effectively places the image inline with the text. The problem with this is there is a gap underneath text for letters that go under the line (i.e. j p q etc.). IE then proceeds to line up the text and the image as per the image below.

Image Inline With Text

This leaves an annoying gap underneath images even when there is no text featured. Just another way Internet Explorer is making our life that little bit harder.