Unintentionally Blank

A whole lot more has been said about meta tag browser version targeting unveiled on yesterday’s A List Apart. Digital Web has quite a few reactions, a list which is worth going through if you want to see what the top people in the industry think of all this.

I have tried to keep up with as much of the conversation as I can and after some revelations today I am actually a lot happier than I was at the end of my post yesterday. Here is the way I see it now.

Continue reading “Version Targeting, HTML5 And The Other Browsers” »

Change is afoot. Every web developers’ favourite publication, A List Apart, has split the split them into three groups today, the content, the annoyed or the confused. The cause of this: Aaron Gustafson’s introduction to Internet Explorer 8’s version targeting feature and Eric Meyer’s thinking process in response to the idea. In a nutshell, from IE8 onwards the inclusion of a meta tag (or server setting) will be necessary to target the version of IE to use to render the page, defaulting to IE7 rendering if no meta tag is found (please see the article for more detail).

This has thrown the developer community into disarray as everyone tries to work out whether this is madness or genius. Jeffrey Zeldman, Jonathon Snook and Eric Meyer think it is a good thing, Jeremy Keith doesn’t, Drew McLellan distanced the whole Web Standards Project from the decision and Andy Budd thinks that IE will be the one to feel the force of the mistake. Here are my thoughts as I pass from the confused camp to one of the other two.

Continue reading “Version Targeting For IE8, Developer Wars, My Thoughts” »

Breaking news! Internet Explorer General Manager, Dean Hachamovitch has posted on the IEBlog to say that IE8 passes the famous Acid2 test.

Acid2 does not guarantee support for any specification, however it does test for support for certain features that are both important to web developers and not yet supported well across the board. According to Wikipedia, the only browsers to pass the test at the moment are:

WebCore-based applications

Safari, the web browser included in Mac OS X

OmniWeb, a web browser for Mac OS X

Shiira, a web browser for Mac OS X

Konqueror, a web browser for Linux

Prince, an XML-to-PDF converter for Windows and Linux

iCab, a web browser for Mac OS and Mac OS X

Presto-based browsers

Opera, a web browser for Windows, Linux, Mac OS X, and BSD

Internet Channel, a version of the Opera browser for the Nintendo Wii game console.

Gecko-based browsers (1.9 or higher)

Mozilla Firefox 3.0 beta 1

A Good Result and Some Bad Timing

Passing Acid2 represents a fantastic step towards compliance and standards support for the Internet Explorer team, quite a turnaround from the news last week that Opera were taking Microsoft to court over their monopoly in the browser department and their lack of support for standards (which caused some ripples around the rest of the Internet).

It turns out that the IE team are probably the ones laughing now though, since the Acid2 test was passed on 12th December, the day Opera filed their complaint with the European Union. At least, it seems like Molly Holzschlag is excited about it, and so should she be, part of her job is to get the IE team concentrating on standards support. I’d like to congratulate all of them and hope to hear more announcements about IE8 soon, as I’m sure any other developer who has had to deal with incarnations of IE in the past. Standards support in the latest IE won’t solve all our problems, but it will go towards making our lives easier in the future.

For now, all I can say is well done IE team and keep up the good work!

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.