Site Navigation

Saturday, November 29, 2008

bug 375 - no window.onresize event in IE8 Beta 2

Issue: #375
Affects: IE8 Beta 2, IE8 PR1, IE8 RC1
MSIE Feedback ID: 410707

MSIE Feedback ID: 390166

MSIE Feedback ID: 377719

MSIE Feedback ID: 364571

Note: There was a partial fix in IE8 RC1 however iframes still do not fire resize events properly.

When IE8 Beta 2 shipped it was a significant improvement over Beta 1 - quite simply by the fact that it was actually usable!

There is however a regression bug (that MS claims is fixed in their internal builds moving towards a Q1,2009 RC1 release) with the window.resize event never, ever firing!

As a result, any attempt to capture this event and execute some JavaScript logic on it will fail. Hopefully this will be fixed in the RC release... but we are wondering... does this mean (bug 104) will also be fixed? or will it behave like IE7 did? or IE6 did?

Known Workarounds: None.

Related Issues: One. (bug 104)

Bug/Site Feedback |
Submit a bug

bug 476 - Slow SVG rendering in IE8

Issue: #476
Affects: IE8

For anyone that has noticed that SVG rendering in IE8 (w/Adobe 3.x plugin) is really slow (like 10 seconds to load a simple image... kind of slow) you'll be glad to hear that there is a solution!

The issue is that IE attempts to load a resource file (script or style) that it can't locate.


<script xlink:href="/js/nonExistingFile.js"/>

To remove the delay that is caused by IE/Adobe Plugin (not sure which is stalling) attempting to find and load your JS / CSS file simply correct your SVG markup to point to only valid resource files.

Known Workarounds: One. Check that you are not pointing to any non-existing resources if you are noticing heavy delays in rendering.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Friday, November 28, 2008

bug 471 - font-weight:600 stretches text in IE

Issue: #471
Affects: IE6, IE7, IE8 Beta 1, IE8 Beta 2, Chrome 5,6,7
Fixed In: IE8 PR 1

Update: This apparently affects Google Chrome now (v5,6,7)

When styling text on your site there are several options for bolding. You can use the classic <b> tag, the <strong> tag, or any tag with styling set for the font-weight.


<style type="text/css">

Every option works as intended with the exception of 600 in IE. IE will render any text with a font-weight:600 about 10% wider than normal text (regardless if ClearType is turned on or off).

The Quick Brown Fox Jumps Over The Lazy Dog. Please Don't Hurt The Web - Use Web Standards. (@500)

The Quick Brown Fox Jumps Over The Lazy Dog. Please Don't Hurt The Web - Use Web Standards. (@600)

The Quick Brown Fox Jumps Over The Lazy Dog. Please Don't Hurt The Web - Use Web Standards. (@700)

Note: Updated the style to a fixed-width font to better illustrate.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Wednesday, November 26, 2008

Google Chrome gets Updated!

Google Chrome: Gets Updated

Just in case you didn't notice, Google has updated their browser from:

AppleWebKit 525.13
AppleWebKit 525.19

As a result some of the navigator properties have changed including the vendor!

Apple Computer, Inc.

Now is:
Google Inc.

Bug/Site Feedback |
Submit a bug

Thursday, November 13, 2008

bug 505 - you can't programatically focus a link in IE unless another link has the focus

Issue: #505
Affects: IE6, IE7, IE8

Here's the scenario: You want to put the current focus on a hyperlink on the page, complete with that dotted border that indicates to the user, that the link has the focus.

Easy enough, right?


<script type="text/javascript">
var firstLink = document.getElementsByTagName('a')[0];

Well, try it out. In fact, just drop it in the location bar of any other browser as a bookmarklet to verify that it works.


Try the same thing in IE, and you'll notice that the dotted border doesn't show up! Press Tab, and you'll move focus to the next filed, press Shift Tab, and you'll move back, complete with the dotted border. The link does have the focus though... press Enter and you will activate the link.

To see how it should work, press Tab to move between the links on the page. Once you are on a link, complete with the visible dotted border focus, now call .focus() on any other link. Thus it only works in IE, if another link already has the focus, and it was achieved manually.

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Thursday, November 6, 2008

bug 512 - can't scroll zoomed page in IE8....... wait... maybe...

Issue: #512
Affects: IE8 Beta 2, IE8 PR1, IE8 RC1

Keeping in mind that IE8 is still in Beta there's an issue in IE8 when scrolling a page up and down vertically and horizontally.

On any page with content (about:tabs) ( ( scroll the page up and down using the mouse wheel, or the scrollbar on the right hand side. (resize window if necesary to obtain scrollbars).

Works like normal, right?

Ok, now zoom in to say 120% or 160% ([CTRL] + [+]) now try scrolling as before.

Woah! what happened? did your performance just tank? on some screens it will take 5-6 seconds to get to the top/bottom.

The good news is that this is just a beta, so there is still plenty of time to fix this. (we hope!)

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

bug 327 - IE limits your CSS file size and contents!

Issue: #327
Affects: IE6, IE7, IE8

So like every Web Developer out there, you've moved all the styling you can to seperate CSS Stylesheets - Great!

Did you know that there are limits? Well no, not in all browsers however in IE there is a limit, in fact a few.

  1. In IE, the maximum size of any CSS file included in your page is ~288kb IE will load up to that point, but will ignore any content after that. (something to keep in mind if you merge your CSS files to avoid multiple HTTP connections!)

  2. In IE, you can only have 4096 style rules, after which all are ignored. (something to keep in mind if you are generating unique styles for nearly every element)

Known Workarounds: None.

Related Issues: None.

Bug/Site Feedback |
Submit a bug

Sunday, November 2, 2008

bug 421 - IE fails to pass the HTTP Referer on many navigations

Issue: #421
Affects: IE6, IE7, IE8, IE9 RC 1
Status: Microsoft has confirmed this will NOT be fixed in IE8 RTM

Lets take a moment to explain... The HTTP Referer: Identifies the address of the webpage that linked to it... by checking the Referer the new page can identify where the request came from. (and uhm yeah, the intentional mis-spelling of this header is a whole other issue)

(Full Wikipedia Referer Def'n and the HTTP/1.1 spec on Referer)

All good browsers send this header on a request indicating where the request came from. The target page/site can then use that information to track backlinks, gather stats on where their users are coming from, improve their marketing, or even block links from an undesired source. Within a site it is handy also to determine the best place to send a user back to, as they may have arrived from any number of sources.

So, what's all the hoopla about? Well IE doesn't always send it. In fact there are several cases when IE doesn't send it, but the most common is this one.


<input type="button" value="Edit" onclick="location.href='edit.html';">

If you click that button in any non-IE browser, it will tell you what site/page you just came from. However if you click that button in IE (even if you cross your fingers and click with your left hand) no HTTP Referer information will be sent.

So in the larger picture if you want to do any navigation in JavaScript, be ready for it to not pass the referer.

Known Workarounds: One. If you create your own page navigation function in JavaScript and use it instead you can force IE to send the Referer. (It won't help you obtain it from any other site that doesn't provide their own fix though)

Example Workaround Code:

//use browser sniffing to determine if IE or Opera (ugly, but required)
var isOpera, isIE = false;
if(typeof(window.opera) != 'undefined'){isOpera = true;}
if(!isOpera && navigator.userAgent.indexOf('Internet Explorer')){isIE = true;}

//define for all browsers
function goto(url){
location.href = url;

//re-define for IE
function goto(url){
var referLink = document.createElement('a');
referLink.href = url;

In this case we define a new function called goto(url) for all the browsers it just sets the location.href to the new value, but in IE we redefine it, so that it creates a link, appends it to the DOM, then simulates a click on that link causing page navigation to occur but since IE does pass the referer on links, the referer is sent to the target page!

(PS for those waiting on the Fish Bicycle, it is coming soon... this bug isn't it)

Related Issues: None.

Bug/Site Feedback |
Submit a bug