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!

Expression Web SuperPreview

Having a play with Web SuperPreview from good'ol Microsoft and I have to say i'm a little disappointed.



It very much aimed and a px by px comparison of two browsers, which in my experience is pretty much a waste of time. I've never had a support call were someone is upset about the look and feel being slightly different on a different browser.

Focusing on minor UI display differences results in designers insisting on using graphic buttons and DHTML scrollbars and code forking in the CSS in order to achieve pixel perfect adherence to the visual design on various target browsers. Not a road that I want to go down.

I think I'll be sticking to IETester and VMs, for now anyway.

Also, i may be missing something blatantly obvious but I couldn't workout how to trigger a control or even follow a link in the preview panel so couldn't inspect any dynamic page elements. I assume that's just me being a twat. The product would have no value at all if you can't interact with the page, but it's not immediately obvious how you do (well, not to me anyway!! : ).

Related links...

• http://www.sitepoint.com/blogs/2009/03/19/microsoft-superpreview-website-tester/


• http://www.sitepoint.com/blogs/2008/12/04/adobe-meermeer-will-change-the-way-you-test-web-sites/


• http://www.my-debugbar.com/wiki/IETester/HomePage


• http://browsershots.org/

Icons and image replacment

Generally speaking i'm not a fan of image replacement, but for inline icons it seems to work a treat. We had this issue that users with screen readers where struggling with our icons that we use liberally in our pages. For example, the "More information" icons that we use on some links to indicate that there is more detailed information available, looks something like this.





Although this looks quite reasonable it was causing problems for screen readers as they list out all images which means the user will get a list of images all saying "More information" (so a bit like having a list of links all saying "Read more..."). This is a problem with using images as text (an icon is really short hand text) if you look at them out of context they don't make sense.

Using image replacement as a way of hiding images from screen readers works quite well, as they are background images and not img tags. If we look at the same link using image replacement...





I tend to use nested spans for image replacment, you may prefer to use a single span with a combination of overflow hidden and a text-indent value, depends what browser support your after. If you don't need backwards compatibility you could just use the CSS "content" property instead.

Are DOM browsers the edge case?

I think the answer might be Yes.

You want your application to work on the web so you write it to output semantic HTML, if you do this without using script (or noscript tags) your site should work on pretty much any browser that understands HTML regardless of platform, OS, browser version etc... that's quite a lot of different user-agents running on, mobiles, iTV, games consols, PCs etc... A subset of these user-agents will understand javascript to some degree, and a sub-set of these will understand DOM. If you then think of DOM browsers as a edge case (albeit an improtant one) everything falls into place.