Unintentionally Blank

Firstly I’m excited. Opera Mini 4 was released last week. I didn’t use the beta as I was happy with Opera Mini 3, but now version 4 is fully operational I have upgrade (though I only just found out… it seems that no-one cares about Opera Mini when there’s an iPhone being released). Secondly, I’m a little confused, Opera Mini 4, like the iPhone’s Safari, no longer supports handheld style sheets.

Quality Browsing On The Small Screen

Opera Mini 4 brings a whole load of new functionality to the mobile web, it’s available for most modern phones and renders full web pages (mostly) as the designer had intended. It allows for zooming in to pages to read the content and lines text up in screen width sized columns. It gives you a virtual mouse that you can scroll around the screen with and click links. JavaScript and AJAX support has also been improved, which is good news for users of modern, JavaScript heavy sites. This is a great step for the mobile web, users will now be even better served when surfing from their mobile and site owners have less to do to make their site compatible with mobile platforms. If Safari on iPhone hadn’t already done this, this would be big news, sadly, even though Opera Mini runs on most modern phones, excluding the iPhone of course, and can modernise the mobile web for many more users, it won’t be.

The Death Of The Handheld Style Sheet

The handheld style sheet is one that can be served to mobile devices using media definitions in the link, like this:

<link rel="stylesheet" href="screen.css" media=”screen” />
<link rel=”stylesheet” href=”mobile.css” media=”handheld” />

The first declaration above loads a style sheet for screen use and the second for mobile, if the browser supports it.

Now you know what the handheld style sheet is, forget it. Today’s premier mobile browsers, Opera Mini 4 and Safari on iPhone don’t pay it any attention. The handheld style sheet is obsolete. Opera’s reason for this was:

[..] the main issue with handheld is that you are not giving the user much of a choice of what content is delivered to their phone. These days, phones are much more powerful than they used to be, and it is a bit insulting to have a web site see you are a mobile device, and then serve you a really dumbed down version of it’s content, even thought the device could quite easily support the full desktop version of the site. If you check out Opera Mobile 8.65, or WebKit on the iPhone, you’ll see a browser of comparable power to their desktop cousins.

This almost seems fair. Opera Mini, Safari on iPhone, Opera Mobile can all create an experience akin to using a desktop, with a bit of zooming in and out and panning around the screen it is all the same. Why give developers the ability to take that away with a handheld style sheet?

My opinion was that handheld style sheets aren’t for removing content or taking away from the experience of mobile browsing, I considered that they were useful for shrinking pages for the mobile platform, taking out unnecessary background images that would only take a long time to download over mobile networks or even organising the content in the right order. Providing a different experience for mobile users is more the realm of browser sniffing and redirection.

Handheld Reincarnation, Already!

Handheld style sheets are back already though, just under a different name. Opera Mini 4 and Safari on iPhone both support CSS3 media queries, allowing you to target styles to screen sizes. In my opinion this invalidates Opera’s arguments for dropping handheld support, since the same effects could be performed through media queries. However, these media queries could be used to perform styling for the mobile devices that I mention above too, so all is not lost, unless you think life for developers could be as hellish as Christian Montoya’s prediction

Conclusion

It looks like handheld style sheets are gone, and media queries and CSS3 are the future. In time, and as support grows for these media queries, we may find use for them in a more general context, shuffling dynamically between 1, 2 or 3 column layouts based on browser size comes to mind, with mobile browsers likely to get the 1 column version.

More importantly, mobile browsing has taken another step forward. If you like to surf on your mobile and you don’t already have Opera Mini, go and get it.

A weird Internet Explorer 6 bug hit me at work recently. One page on a client’s site repeatedly crashed IE6. Not one of the usual CSS support bugs that can be solved with a bit of tweaking and reloading the page to see if it worked, every time I visited this particular page in IE6 the browser just bombed out.

An hour of headaches and starting up the decrepit browser over and over again lead me to the cause of the problem, a seemingly innocent <input type="button" />. Comment out the input and the page loaded, leave it in and IE6 lost it. For the record, IE7 handled the page superbly. But having found the cause of the crashing to be an input, the problems weren’t over, I couldn’t just remove the button as it was necessary for saving the form on the page. More investigation was needed.

The IE Duplicate Characters Bug

After a while I decided to replace the input with text, to see whether that would have any adverse effects and it was the right thing to do! The text appeared twice on the page and I instantly searched for any documentation of duplicating text in IE6. Position Is Everything came to the rescue with this explanation of the IE duplicate characters bug. It turned out that a combination of floats and comments or hidden elements causes text to duplicate if it is in a particular spot. In my case, there was an input in that spot and rather than duplicating the input, the browser just gave up.

A bit of fiddling with comments and moving hidden content around finally left the page in a state to be viewed safely by IE6 again. Sometimes Internet Explorer amuses me, this just confused me for a long time, had I not replaced the input with text I could even still be pondering it. It goes to show that with a lot of time and a bit of luck, you can avoid (most) IE bugs and get your pages back in working order.

Since starting full time in the web development industry 4 months ago I have picked up a number of different tools I use every day to make my life easier and my coding quicker. A lot are based on my favourite browser, Firefox, some can be used with any browser and others are the simplest of text editors.

Over the coming weeks I am going to share with you my experiences of each tool I use daily for development. With any luck I will introduce you to a few new tools that you may not have heard of and will help you out. I would also like to hear what your favourite development tools are too and if there are any I am missing out on.

So, keep an eye out for my web developer tools series, first part coming out later this week.

I broke this script and have fixed it! Please read about it and download the script from this post.

A long time ago I wrote a script that changes font sizes. In the year since, I have learned a lot about JavaScript and accessibility and looking over the code I wrote I was ashamed! I will dissect the mistakes I made in another post, but for now I have re-written and vastly improved the script.

Improved Functionality, Improved Accessibility

The script now does everything for you without you having to change your markup, so it degrades nicely when JavaScript isn’t available and it uses (mostly) standards based JavaScript (but don’t get me started on Internet Explorer support for setAttribute).

Once the DOM has loaded the script will check to see if the font has already been set by trying to read a cookie (cookie script was originally from Quirksmode). If the cookie is found then the font size of the body element is set to the previous value. If no cookie is found then the script creates an element and measures the height of it to work out the current font size (thanks to a script on detecting font resizing at A List Apart) and sets that as the cookie. It then adds three links to the document, appending them to an element of your choice. The three links increase, decrease and reset the font size, saving the changes to the cookie.

How To Use It

Now all you need to do to use the fontSizer is:

1. Download the script (there is an updated version with class names below)
2. Change the string “fontControls” at the very end of the script to the element you want the font sizing links appended to.
3. Upload the script to your server
4. Include the following line in the <head> of your document:
   <script type="text/javascript" src="fontSizer.js">
</script>

When you visit the page you did this on, you should find that three links appear: A+, R and A- (they’re not pretty, but customisation is left as an exercise*). On clicking A+ the font size of the whole document will increase, clicking A- will decrease the font size and R will reset it to the original size. The script has been tested and works in the following browsers:

• Internet Explorer 5.5, 6 and 7
• Firefox 2
• Opera 9
• Safari 2
• Camino 1.5

I have also provided a (very simple) example. So, if you want to add an unobtrusive, accessible way of increasing your website’s font size, please download the fontSizer script and use it!

If there are any problems, please let me know and I will do my best to help you out.

As requested in the comments, I have updated the fontSizer to include class names for styling the links. The “A+”, “R” and “A-” will now come with the classes “increaseSize”, “resetSize” and “decreaseSize” respectively. If you want to change them, just have a look into the source code and you should see where they are set. The new version is available to download now.

* I have always wanted to say that!

I am looking to rework a couple of my scripts here at Unintentionally Blank as in the time since writing them I have learned a lot about accessible, unobtrusive JavaScript. My old scripts no longer cut it and it is time to improve them. Before I start, I wanted to beat window.onload, the event that tells your JavaScript functions that everything has loaded and you can use the DOM now. I had heard of solutions to this before, but now I was to start developing these scripts again I wanted to find the best solution.

Why Take On window.onload

Unobtrusive JavaScript relies on externalising all your JavaScript code and calling it in via <script> declarations in your HTML document’s <head>. With this method, adding functions to elements in the document needs to be done by attaching event handlers which classically was done with window.onload. However, window.onload only fires once the document and any elements in the document have loaded. So, if you have large images or lots of them the window.onload event will not fire until everything has loaded. This has the potential of leaving any elements you want to give events to go without them, potentially allowing users to click on these elements and not receive the enhanced behaviour that your JavaScript was just waiting to provide.

Beating window.onload by adding event handlers when the DOM, but not necessarily the content and images, has loaded reduces this time and quickens the page’s response.

The Solutions

Looking around the internet threw up a number of increasingly complicated solutions. Dean Edwards seemed to come up with the original solution which was steadily improved until a final version as released (and subsequently used in the JQuery library, I believe). Peter Michaux followed up with some increasingly complicated stuff to remove the time between the page becoming visible and the events being attached, but the Dean Edwards method seems to work for most applications on a small scale.

Following in the footsteps of Dean and packaging the function up into a standalone solution was Jesse Skinner with his addDOMLoadEvent. Not only did this implement the solution nicely, with all the updates that have occurred since the original solving, Jesse also compressed the function as best as possible. The current version stands at only 671 bytes in size and works in Internet Explorer, Firefox, Opera 9 and Safari, plus degrades nicely to use window.onload for any browsers that don’t support the technique.

Coming up soon then, will be the return of my scripts, faster, more accessible and generally better than ever before thanks to this and other techniques I have picked up over the last year. It will be like an early Christmas present, I can’t wait!