The main problem is that the site has a Javascript heavy interface, which relies on a fairly non-standard click & drag model. Mobile Safari has fantastic support for web standards, but because it’s not a mouse & keyboard kind of device, a lot of the desktop interface model doesn’t seem to apply. Thus a lot of the more funky functionality in this site simply won’t work.

As I don’t have an iPhone myself (and don’t plan on buying a bunch of assorted handsets to test sites on,) I went in search of the next best thing; the iPhone simulator in the SDK. The main problem is that the SDK itself costs up to $300 per seat and only runs on the Mac. That’s a little bit steep considering all I want to do it run the browser emulator so I can get this site working nicely in Mobile Safari. I’ve been corrected by Tate that the SDK only costs if you want to publish software for the iPhone.

Some other web devs have touted desktop Safari as an appropriate tool for testing iPhone sites in, but aside sharing a base rendering engine they’ve got almost nothing in common. There’s a large number of curious quirks in the mobile version that simply don’t exist in any other browser, and patching them without having access to a handset seems highly improbable.

Essentially non-Mac developers are stuck with guesswork and contortionist tricks until Apple either releases a mobile mode for Desktop Safari, or opens up the SDK. Neither of these things are overly likely considering that most Apple products heavily apply the principle of vendor lock-in.

I’m hoping I will be able to fix the issues on this site without resorting to buying myself a second hand iPhone, but in the future it may not be so simple. For one of the most prevalent mobile Internet devices on the planet, it has a very high barrier to entry for development.

Fonts were plugged as one such example of improved rendering, although if the IE developer team is worth their money (they have certainly been doing a good job with IE8 so far,) they’ll be looking into squeezing as much performance out of DirectX as they can.

Internet Explorer for the uninitiated has traditionally been slow. The effect has been exacerbated by the latest versions 7 and 8 by a large memory-hungry interface that chugs even on moderate systems. Gone are the days where Internet Explorer was the “fastest” browser, because even when it’s preloaded into RAM, rival browsers like Chrome are orders of magnitude more nimble.

While the cost of processing has been steadily decreasing, the so too has the complexity of rendering for the web. While it’s fine to wait a few seconds for the browser to launch, having to wait repeatedly for pages to load or Javascript animations to complete can become frustrating. Especially with libraries like jQuery and Prototype putting the power of animation into the hands of people who would never previously have considered such effects feasible, we’re starting to see a lot of swooshing and fading that Internet Explorer quite honestly seems to choke on.

Sunspider shows remarkable improvements in Javascript rendering for Internet Explorer 9. It's still the slowest browser, but is now at least comparable to the others.

Hardware rendering will help alleviate this considerably, and I’m surprised it hasn’t taken off before now. Using a recent Opera build, I recently remarked that scrolling was so smooth, it had to be hardware rendered. It wasn’t, but my point is that it’s unusual to find the smoothness of say, iPhone browser scrolling on Firefox or especially Internet Explorer.

It will be interesting to see whether other browsers follow suit, and whether this will have such drastic performance improvements as can be noted in the graph halfway down the IEBlog write-up. It’s fantastic to watch the innovation coming from the different browser camps, and I’m anticipating IE9 will finally be the browser that we won’t tear out hair out trying to use.

Where We’re At

The browser has matured considerably since its first incarnation, to the point that it’s now stable enough for production use.

Climbing steadily in usage since it was released, it’s now reached up to 7% of the market share in technical circles. This is more than both Opera and Apple Safari combined, which is quite astounding. It’s reached incredible inroads in such a short time, and there’s no denying it’s now a big player in the market.

It’s difficult to tell where these users have come from, but with Internet Explorer 7 and six both haemorrhaging users, it’s a pretty fair bet a lot of these people are skipping the upgrade to IE8. Aggressive marketing also plays a part in this gain, with viral videos achieving success overseas and the Google homepage offering Chrome as an upgrade path to IE6 visitors.

What to Expect

Introducing friends and family members to the new browser has had mixed results. It still has quirks I haven’t worked out.

One such issue is the proprietary interface not matching the OS. On the ageing Windows XP, the iconic blue Chrome interface is a breath of fresh air even if it is unusual. On Vista it’s purportedly quite nice with Aero enabled. Conversely on Windows seven it’s terribly out of place.

• The official Linux build of Chrome 3 suffers the unfortunate interface unkindly. The default colour is a stark contrast to any native Ubuntu application, and the native compatibility mode is a cheap mimic of the native GTK (GTK is the native UI toolkit.) The only consolation is an option to use the native title bar, which is a band-aid solution as the widgets are still unusual.
• Chrome on Windows 7 looks terrible. I couldn’t get it to use the Aero effects, rather it stayed repugnantly blue and insolent. The Chrome icon also seems stuck in the Windows XP era, and won’t scale bigger than 48*48. This means it shows up on the desktop as a smaller icon bounded by a box.

While these problems may be overcome in the future, it’s a keen demonstration as to why effort should have gone into an intelligent cross-platform interface instead of hooking directly into the Windows-only “WPF.”

Multi-user Quirks

While Chrome is a great power-user browser, it’s still not suited to multi-user Windows environments.

I’ll freely admit it’s been a few months since I last tried this, but installing Chrome on a shared system for multiple users simply doesn’t work. You can set it as the default browser, but none of the shortcuts show up for anyone else other than the account you installed it with.

This is obviously a barrier that’s going to need sorting out.

Chrome in the Enterprise

There’s also been mixed reviews on Chrome in the enterprise.

As Internet Explorer becomes gratuitously more bloated and difficult to use, Google’s in an ideal position to push Chrome for enterprise use. Enterprise Chrome doesn’t seem to be gaining much ground, mostly because it’s still not easy enough to support.

The sticking factor is the large enterprises using ActiveX and primarily Microsoft technology. Chrome offers few to no incentives for this kind of large-scale corporate environment, because it’s tied to Google services, not configurable through group policy and otherwise offers no tools for mass-rollouts.

The redeeming factor is the “Google Apps Desktop Features” which will integrate Gmail, Calendar, Docs and other hosted offerings with Windows. This is an interesting move to make Google’s hosted offerings as integrated as standard desktop applications, but it’s still a manual install, which makes unattended roll-outs difficult or impossible.

At this point Chrome looks to be a boon to small businesses relying on the Google platform, but it doesn’t offer anything compelling for larger businesses running on Microsoft platforms.

What’s next?

It’s entirely to be expected that Chrome will mature further, and judging by the innovation and intelligence that’s been focused on it already, it’s bound to solve a lot of these problems I’ve presented here.

It’s already a strong competitor on the desktop, and the closest competition seems slow and bloated by comparison. It looks like Firefox — the old favourite “faster browser” — has been well and truly de-throned in the speed department, and Chrome holds the new title for overall user experience even if it still has some market share left to pick up.

Unfortunately for us web developer types, the default code simply doesn’t work with the latest web standards, namely XHTML 1.1. While it may work with earlier transitional versions of XHTML, it chokes when it’s included in a properly validating XHTML 1.1 page because of the use of some fairly questionable techniques.

The main problem we face is that the script uses the unsupported document.write method to insert a <script> element into the document, which will do exactly nothing in a proper XHTML page. Ideally we should be using document.createElement to insert such an item, but for this purpose it’s really overkill. Here’s why:

Remove the document.write

If we look closely at the ga.js sample code Google Analytics gives us, we can see that the first half of the script is performing a simple conditional query to determine whether or not our page is being served over insecure http or secured https.

If we work through the code, we can easily remove the Javascript condition and turn the script into a plain old external javascript which is perfectly acceptable in the world of the XHTML DOM.

<script type="text/javascript" src="http://www.google-analytics.com/ga.js"></script>

Return SSL Support

The above script will now be perfectly usable for our regular http transactions, but what about pages delivered over ssl?

The browser will throw an error complaining that some of the items on the page are being delivered insecurely, so we’ll need to adjust the script accordingly.

<script type="text/javascript" src="https://www.google-analytics.com/ga.js"></script>

Contextual Loading

We can do this manually by including the separate scripts in the relevant locations, or we can use PHP to simplify the process for us. The following script will dynamically decide whether to display the secured version or the plain version depending on the page context.

<script type="text/javascript" src="http<?php if($_SERVER['HTTPS']) echo 's' ?>://www.google-analytics.com/ga.js"></script>

While plenty of neater solutions exist, this is a simple cut & paste script that you can use in your own projects. Just make sure to include the second part of the tracking code as is, and everything should start working in your valid XHTML pages.

Enjoy your newfound, and completely valid Google Analytics code.

That came as a bit of a shock, because we’d tested it in everything we could think of. I’d even installed a copy of Netscape 4 for the occasion. Nevertheless, whatever we did resulted in half of our “white on black” form elements having white text on a pale yellow background.

One of of the clients with the problem brought in their laptop to show us what was happening, and we spent a grand total of five minutes searching in vain for what was causing the problem. There was nothing hexadecimal, RGB or otherwise specifying that pale yellow background colour on our forms, so we took a different tact.

The conclusion was slightly anti-climatic and simple to fix, but the cause was the strange part: We isolated the problem to Google Toolbar and its form completion functionality. Whenever it offered to auto-complete a form for you, it would change the background colour of a form element to this sickly pale yellow colour, but leave the foreground colour whatever was specified in the style sheet. We’d found the source of our “white on yellow” forms.

After that, it was a simple matter of giving the background and foreground colours an !important declaration, which stopped the toolbar from changing the colours. Everything was fixed.

We would have been fine leaving the toolbar to change the colour scheme if it had done it properly. Nevertheless, this is an important lesson to everyone looking to dabble in accessibility: If you’re going to set one colour, set them all.

The standardisation format war between OpenDocument (sponsored by a consortium of people and businesses), and Office Open XML (Sponsored by Microsoft, for Microsoft) has just started to heat up. The Microsoft document format is undergoing a vote to fast-track it to ISO standardisation. This will benefit nobody, except nobody since there are already a number of formats that can be used to do what Microsoft is arguing OOXML is unique for. Still, the fact that the standard hasn’t been shot down from the start means that there’s trouble a-brewing.

Some preliminary points about Office Open XML:

• What’s with the confusing name? OpenDocument used to be called “Open Office XML”. Now the Microsoft format is named “Office Open XML”. Is that deliberately confusing, or just a by-product of a confusing spec?
• The OOXML format spec itself is lengthy, cryptic, contradictory, and contains numerous inadequately documented and Microsoft Office specific quirks that serve no real purpose other than to be backward compatible with older versions of non-standard file formats.
• The format itself is tied in with Microsoft patents, and the disclaimer that Microsoft provided, doesn’t adequately protect end users and developers against patent litigation.

So now that we’ve got that out of the way, what exactly am I on about?

Recently a number of members of the ISO responded to the OOXML submission with the issues they found with the spec, and the EMCA (another standard body that Microsoft initially submitted the “standard” to) responded to that. A few of the responses were good, but a number of them amounted to nothing more than “we can work that out later”.

One of the biggest cop-outs I’ve heard for a long time is in response to the issue of “overlap in scope” between OpenDocument and OOXML. The ECMA argues that OOXML is significantly different from OpenDocument because instead of just being any old document format, it includes a way to preserve the formatting of legacy document formats.

Whoop-de-doo.

I don’t need to buy a three-hundred dollar application to convert my old documents into a new format. I especially don’t need a completely new and incompatible standard to do so. There’s absolutely nothing stopping someone writing an application clever enough to convert, for example, Word Perfect 6 documents losslessly to OpenDocument as the ECMA responses are implying can’t be done. The major selling factor for standardising OOXML is that it has a load of additional cruft to support upgrading from legacy document formats, and that makes it “practical” they both be standards.

It’s a very clever card, considering a big driving factor behind standardised document formats is that they guarantee archived data can be read in the future. Up-selling the “compatible with old document formats” aspect of the spec is bound to rouse the interest of many organisations looking to standardise and preserve their old documents. Even if it means a grubby, six-thousand page specification that nobody in their right mind would bother to implement.

So it will be interesting to see what happens. Either way, I can’t see Microsoft adopting OpenDocument. They’ve got way to much riding on the integrity of their office suite, especially considering the dismal adoption of Windows Vista. Microsoft Office is quickly becoming the flagship product from Microsoft, and implementing another new default document format will definitely be an expensive and embarrassing blow to their reputation.

I haven’t studied the specifications, so some of these conclusions have been drawn from extensive research. The ECMA responses are available as a 305kb PDF document.

Internet Explorer 7, despite my hopeless optimism turned out to be little more than a new interface on top of the joke that is IE6. They also removed a few quirks that don’t actually make designing for the web any easier, but wholeheartedly screw it up.

IE6 is something I can deal with. I can install it under Linux, and that’s fine. IE7 is completely unpredictable, and sufficiently different from IE6 to be concerned about. It can’t run on anything other than a validated copy of Windows XP. Not on Windows 2000, not under WINE. The only way to get it running under Linux is to buy another Windows XP license and use a virtual machine.

That is what I call irresponsible, and from a major corporation like Microsoft, I expected better. I probably shouldn’t have, but that’s beside the point.

If I release code under the BSD license, you can do almost anything you want with it as long as I’m credited for my part of the work. That’s all fine and dandy. With the GPL the authors that contributed before you have a lot more control over your subsequent contributions — it sounds a little like a pyramid scheme if you don’t agree with the GNU philosophy.

There’s another thing I can’t stand in the world of licensing: Thoughtless phrases like “free for non-commercial use.” Why should I be allowed to use a piece of software at home, in the park, at school, but not at the office? What is the difference? There’s none, but because it’s been the standard tagline of proprietary software for so many years now, it’s become ingrained into the way people think.

Considering this, I’d like to point you over to the GPU page on sourceforge where the developers have modified the GPL to include Asimov’s first law of robotics. It’s a seemingly innocent thing to do, but at the same time it’s caused an uproar for all kinds of reasons.

My primary thought regarding changing a well-known and accepted license to include a seemingly trivial addition is this: Why bother? Aside the fact that it will give you a little thrill every time you read it (“Hey, aren’t we funny, look!”) what purpose does it really serve?

People have said it’s a good idea: This way the armies of the world can’t use the software to kill and maim. My take on the issue is that even if the righteous American war lords respect a software license, there’s always going to be people who don’t. There’s no way you can shame someone into respecting your intellectual property if they’re pointing a superweapon toward your face.

So when it comes to issues like this, there’s a need for software, the software exists, and no license is going to stop anyone who’s really intent on using it. I know that if I had a battalion of troops at my front door hungry for my blood, I’d use all the help I could get to get away. In addition, there’s no point taking away one more freedom from a license that’s designed entirely to hinder your right to modify and redistribute in the first place.

I don’t disagree with the GPL as I don’t see the overwhelming need for it in my line of work. Pascal has a somewhat less inflammatory coverage.

What this means is that all traffic to www.mysite.com now redirects to mysite.com. I’ve been meaning to do this for quite some time now (I don’t understand why the major web servers don’t do it by default), but the no-www site had a nice snippet of apache config that’d do it for me. You might sympathise, things tend to get done quicker if I’ve got someone to copy off.

So if you’ve got any bookmarks or whatnot there’s no need to update them. In fact, this probably doesn’t affect you very much at all. I just thought it was worth pointing out that the www prefix is a relic of the old days and old ways, and sites that use it primarily are silly.

This tutorial is aimed at people who feel comfortable editing their own HTML. If you use Dreamweaver or Nvu and are unfamiliar with the HTML markup itself, I’d suggest you open up the source in Notepad and have a play around with it first.

First step: Validation.

One important thing that lots of people tend to miss is the doctype, or document type. The doctype tells the browser which version of HTML you’re writing. Not only that, it tells the aliens who find your markup floating through the void 5000 years from now how the document is laid out. Consider it as a notice saying “Ok, I’m using the English language here, so don’t read it as if it were Spanish.”

I’d suggest you use the XHTML 1.1 Strict doctype, entirely because it’s the latest and greatest. What this doctype tells the browser is that your HTML abides by the XHTML rules, and anything else in the document is a mistake. This is a good way of looking at things, because opposed to mucking together HTML and testing it in all browsers, any browser that understands XHTML 1.1 will render it exactly the same. If by some freak chance you use a browser that doesn’t understand XHTML 1.1, then you’re in luck because it’s backward compatible with older HTML versions anyway.

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>

Above is the XHTML 1.1 doctype. It’s usually the very first line in an HTML page. If you haven’t got a doctype, (you’ll notice if you do,) chuck this one into the top of your page.

The Validator

Next up I’d suggest validating. Validation is debatably important. Some people don’t think it’s any use, but I tend to think it is. In any case, if you run your web site through the W3Cs validation gizmo, it’ll bring up a list of areas you need to focus on. Don’t be concerned if your page gets a whole handful of errors, most of the time it’s just the same error repeated throughout the page, and sometimes one part of your page can cause errors throughout the rest.

If you take note of the errors the validator gives, and then work through them until there’s none left, you’re well on your way. Often it will only be little things, like using a <br> tag instead of a <br />, or using an attribute that’s not supported. If you have to take out an attribute like bgcolor from an element, never fear, we’ll get to that next.

Climb Aboard the Semantics Train

Semantics are one of the big things in web development these days. Lots of people might not understand or care what that means, but it’s rather important for the health of the world wide web.

Semantics is defined as the study of meaning in language. When you’re writing HTML, it’s just another language. Admittedly it’s a markup language as opposed to a spoken language, but think of it like this: If there was no meaning to your language, how would anyone understand what you’re trying to say?

The interesting thing is that there are two layers of meaning when it comes to HTML. There’s the version that your browser displays from the markup, and then there’s the markup itself. The browser does all the hard work, and interprets the HTML to the best of it’s pre-defined abilities. When you navigate to a web page, you see the render level semantics. Imagine, however, that there’s no browser. How would you understand what the markup is trying to say?

By using meaningful elements, of course.

Semantic Elements

Certain elements in HTML were introduced to be used for certain things. A <p> tag is used to start a paragraph. a </p> tag is used to signify the end of a paragraph. In the same way, an <img> tag is used to represent an image, a <li> tag is used to represent an item in a list, and a <table> tag is used to tabulate data.

If we were to start using p tags to generate whitespace in a document, or using table tags to lay out images, we’re breaking down that lower level of semantics. Sure the web browser might do a good job of making it make sense, but anything else (Including search engines) have no idea what you’re talking about, and simply try their best.

This is why it’s important to use the right tools for the job.

Keeping this in mind, go through your document, and try to remove any elements that aren’t being used properly. Again, try to add elements where they make sense. Using an unordered list for your menu, and proper heading tags is a good start (If you think something looks ugly, you can style it later).

Content from the Layout

Another interesting concept in modern web design is that you can completely separate the content from the styling. If you view the source to this web site, you’ll notice that there aren’t any font tags, or colours defined in here. That’s because all of the layout has been left to the CSS.

If you’ve kept reading this far, you should at least have some idea of what CSS does. Essentially it is a way of specifying how an HTML page should look — it adds a layer of style to the page. Many older sites use it primarily to set the font and change the colour of a page, while still using html attributes to do the rest.

Let me tell you: It’s much, much easier to use CSS for absolutely everything design related on the page.

To do this, you may need to do a little bit of reading into CSS. There’s an excellent tutorial at w3schools which I highly recommend.

• A short note of advice: Internet Explorer six and seven do an absolute farce of a job rendering anything but the simplest of CSS, so you may have to tweak your design or use conditional comments until it works in everything.
• Another trap that some people fall into is using a div per line. CSS styling is not restricted to divs. You can set the height and width and border of a paragraph, you can float it left or right. You can do pretty much anything with any element, so don’t go forth thinking that only divs can be styled.

Your New Site

Finally, your web site should be resembling something of a work of art. If you’re like me, you’ll always be finding better ways to be doing things with what you’ve got. This is awesome, because it means you’re always learning how to better your markup. I wish you luck and happiness on your new design endeavours, and hopefully one day you might be able to teach me something too.

If you’re feeling brave, I encourage you to modify and expand on this document where I’ve failed to cover something. Feel free to send in any URLs you found useful in your adventures. I also invite feedback, so leave a comment and I’ll see if I can incorporate your ideas somehow for the next person.