IE, butters text after filter is applied

In my little world IE8 usage over took IE7 for the first time last month, so decided to try to sort out my JavaScript fades which I disable for IE. The problem with the fades is after the fade in ends the text is blurred, fuzzy and generally butters!

TODO: add image of butters text...

I haven't looked into this in any great depth, but the problem seems to be with clearType text in IE and obj.style.filter. If you apply the Alpha(opacity) filter the text gets mashed up, so setting obj.style.filter="Alpha(opacity=100)" breaks the anti-alias on text.

One work around is to set a background colour on the element your going to apply a filter to. If you don't know which elements your going to fade in advance you can reset the filter after the fade has run, which isn't ideal but better than nothing.

I user a method similar to the bellow for setting opacity

/** @id Transition.SetOpacity */
function SetOpacity(el,opacity){
    opacity = (opacity>=100)? 100 : opacity;
    el.style.opacity   = (opacity / 100); 
    el.style.MozOpacity  = (opacity / 100); 
    el.style.KhtmlOpacity  = (opacity / 100); 
    
    // private method to set opacity in IE
    setIEOpacity(el,opacity)
  
    function setIEOpacity(el,opacity){
        if (!el.currentStyle.hasLayout){
            // give element layout
            el.style.zoom = 1;
        }
        if (!el.originalFilter){
            // save the original filter, if one exists, so you can replace it after fade 
            el.originalFilter = el.currentStyle.filter || 'none';
        }
        // if opacity = 100 put the original filter back
        el.style.filter = (opacity == 100) ? 
            el.originalFilter : 
            'progid:DXImageTransform.Microsoft.Alpha(opacity='+ opacity + ')';
    }
}

NB. for a fade to work in IE at all, the element needs to have layout (obj.currentStyle.hasLayout) this is a read only attribute, to set it to true you need to give the element a style that will trigger it to set .hasLayout to true. I normally set the zoom style to 1 in an IE only stylesheet. For other ways of tringering hasLayout see haslayout.net

Forms, field by field error checking

Like most developers for the past couple of years I've been implementing form checking on a field by field basis so when a user is filling in a form field the client side error checking is run. This has a couple of advantages, firstly the users gets the errors there and then, so when they get to the end of the form it should be valid and ready to submit, also it's quite fun to implement!

However, I was reading some research (which I have now temporarily misplaced!) which calls this approach into question. The basic premise was that in regard to form filling, the brain works in two different modes, the 'create' mode and the 'edit' mode.

In light of this the best way to handle forms is to allow the user to fill in the form (brain is in create mode) then validate all the elements in one go, so the user can go back over the form (brain in edit mode) to fix any errors. This was tested and found to be better than making the user switch from create to edit mode on a form field by field basis.

I'll try to find the relevant article, unfortunately my brain is in permanent 'confusion' mode so that may take some time!

Good bye browser matrix...

Is it time to just say "So long, and thanks for all the fish" to the browser matrix?


The browser matrix was quite handy in days of yor, when browsers worked in quite fundamentally different ways from each other (remember NS4 vis IE4?). Nice then to just pick a couple of browsers to support, you couldn't really expect your site to work on anything that you hadn't tested it on anyway.

So why don't we need it anymore?
Well, for a start if your using progressive enhancement you could expect your site will work on any user-agent that understands HTML. In which case what does "Support" actually mean? The notion that a website supports a specific browser OS combination is an old school way of looking at the web.

What's really the problem with saying that a site supports a particular browser though?
Well, let's look at what we really want from our website in the first place, we put our site up on the Internet, it's available to anyone, so we want it to work as well as possible, on as many user-agents as possible.

How should we achieve this?
The browser matrix method encourages developers to adopt a blinkered approach, we ask developers to build a site that works on browsers A, B and C. They build it using A and then debug on B and C, job done.

So where does that leave users of browser D?
Testers don't check browser D because its not on the matrix and any bugs that do get raised by users get rejected as "Unsupported user-agent" for the same reason. So, over time the browser matrix is a self for filling prophecy, the site will only work on browsers A, B and C.
There is another interesting aspect though, the notion of a browser being "Supported" changes the responsibility of the developer, if browser C has a bug in it that results in a visual formatting issue, the fact that the problem is a bug in the browser is irrelevant, because browser C is supported the developer has to accommodate the bug in the website, this means hacks and work-a-rounds in the code. The result of which means the more supported browsers in the matrix the more bloated your site gets as more and more browser bugs get accommodated for.

So what's the alternative?
The best alternative to having a browser matrix, is to NOT have a browser matrix!

Let's look at a scenario; we ask our developer to build the site to work on a text only browser, and give them a visual design or two of how the site should look on a desktop browser. The developer makes semantic, working HTML and enhances it to match the visual design, not having a matrix to work from the developer checks the enhanced look and feel on the browsers they have on their machine, likely the latest versions of the main browsers, the developer then hands the site over to testing.

The testers, without a browser matrix to follow, will start testing the site, they are likely to check the analytics of the site, or of a similar site, to see what user-agents people are using and organise their test effort accordingly, as well as that, they will test on any user-agent they have to hand, they can't help them selves!

Other people in the company will also raise bugs as the user-agent they are using is no longer "Unsupported".

Okay, so we have anarchy!
Our developer has loads of bugs assigned against the UI, how do we handle them all?

In actual fact, it's quite easy, bugs can be prioritised quite quickly by assessing a number of factors:

* What is the impact of the bug to the user? (is it a show stopper?)
* What is the frequency of the effected user-agent? (is it a high frequency browser?)
* How easy is it to fix
* What is the negative impact of fixing the bug? (e.g. do you have to introduce code forking?)

For example; bugs come in around visual layout in IE6, impact on users is fairly high, it's a high frequency browser, easy to fix and impact on other browsers is nil as we can fix issues using conditional comments for IE6 only, these can be done ASAP. So basic common sense really!

In the end the simple fact that more issues are know about will help and the site get better over time, since it won't get held back by the existence of a Browser Matrix.

Font size switching, yes again!

I was just having the font-size switching conversation with someone. I was banging on about our policy which is tell users how to change the font size in their browser, rather than duplicating this functionality with client side script.

All very well, but down at Shaw-Trust they (pretty much everyone) prefers the click to change method (e.g. three varying size "A"s next to each other and you click on the one you like the size of... www.webcredible.co.uk).

But, I complained, if you set the size of text you like in your browser then text in all websites sites, that aren't fixed size text, will be the right size?

Yes, but some sites don't support changing text size and break.

What do you mean? Either a site will be coded old school with fixed font size, in which case it wont change or it be relative size and will work?

No, some sites have relative font size but don't support larger sizes so if you change the font size in your browser the layout will be broken and you'll need to change it back in order to use the site.

You can't be serious, show me a site like that...

www.virginmedia.com (try IE with anything other than default font size)

oh...


IE6 Screen shot with larger and normal font size...

@media nasty hacks

What with IEs conditional comments its been a long time since in needed to do any CSS hacks. Being a bit out of practise it goes against the grain to add stuff that's obviously wrong just to get something to display in one browser or another. Still, what are you going to do? Telling people to change their user agent is not really a viable option. The particular problem I was trying to hack was on Opera mini on the Blackberry, so took to delivering a little CSS for that it could understand to fix the layout issue.

/* hack to fix search form in Opera mini */
@media screen and (max-device-width: 480px) { 
 html #search-options,
 html #search-options div.searchOptions,
 html #search-box,
 html #search-options div.searchBoxWrapper,
 html #search-options div.searchBoxWrapper div.searchBoxContainer,
 html #search-options div.searchBoxWrapper div.search-btn {
  height:20px;
  overflow:hidden;
 }
}

As you can see, fixed the heights of a load of divs which fixed the layout issue. So only problem is, this breaks they layout that worked perfectly well before in the iPhone! So I had to add yet another hack to reset it back to how it was...

/* remove for webkit */
@media screen and (-webkit-min-device-pixel-ratio:0){ 
    html body #search-box  {
       height:auto;
    }        
}

It's like 1999 all over again! Anyway, question is, is there a better opera mini only way to write the first hack which won't get picked up by other small screen devices???

I shall investigate (at some point!)

Mouse over menus and delay

Just been looking at menus, not for the first time nor the last. One thing i picked up on in Jakob Nielsen's Alertbox is his opinion that mouse over menus should appear after a half second delay, this is to reduce the irritating flicker you get when moving the mouse around a page. I've only seen this implemented a couple of times, can't remember where, but I totally agree with this approach.

I'm much more of a clicky menu person myself, but if you must go mouse over then, delay before showing and delay before closing too!

Related links

• http://www.useit.com/alertbox/mega-dropdown-menus.html
• http://www.smashingmagazine.com/2009/03/24/designing-drop-down-menus-examples-and-best-practices/
  

JavaScript support levels

Generally, i breakdown JavaScript support into 4 levels. This makes life much easier and as i'm a lazy bas****d it suits me to keep development time down to a minimum.

I'm using something like this...

 window.user = {
 jsSupportLevel : 0,
 init: function(){
  if(!document.getElementById){return;}
  var ua=navigator.userAgent.toLowerCase();
  var platform=navigator.platform.toLowerCase();
  var isPC = (platform.match('win32')||platform.match('win64'))?true:false;
  var isDeskTop = ( ua.match('firefox') || isPC || platform.match('macintel')  )?true:false;
  var support = 1;
  if (window.XMLHttpRequest){support = 2}
  if ( support==2 && isDeskTop ){
   support = 3;
  }
  this.jsSupportLevel =  support;
 }
};user.init();

This will give you a js global "user" and you use it in your js to determine whether to do some enhancements or not.
e.g.

if (user.jsSupportLevel>1){
   ... attach Ajax related event handlers ...
} 

Example support levels

0 = user-agent doesn't understand DOM (!document.getElementById)
1 = user-agent DOM enabled
2 = user-agent has native ajax support (window.XMLHttpRequest)
3 = user-agent is probably a desktop browser

You can use the above to deliver the appropriate level of JavaScript support to users, e.g. Don't implement any JavaScript if the support level is 0, only do very basic JavaScript for level 1, do pretty much everything for level 2 and level 3 is level 2 with transitions and opacity (stuff you wouldn't want on a mobile/hand-held).

This will only work if your using progressive enhancement of course!