This is good news.

Advertise here with BSA

Firefox has been all over the news lately with the release of Firefox 4, the latest version of what was once my eye-opening favorite browser. Lots of browser talk focuses around performance. Every time a new browser version comes out many of the intro paragraphs for reviews mention ”OMG FASTTTT!” at least once. Speed is of the essence online, and the browser can have a large impact on that experience. Mozilla is doing something interesting by ranking Add-ons with the Slowest Start-up.

I wasn’t surprised to see Firebug, arguably the most impactful browser add-on in the history of browser Add-ons, but I was surprised to see it tied for first place as the slowest performing Firefox Add-on. I switched to OS X in 2006 and the first thing I noticed was that Firefox felt slower. I asked around and others confirmed that although it was their primary browser, it did in fact feel slower on a Mac.

Time went on, and Web Inspector came about, resulting in Safari finding a home as my default browser, as Firefox continued to grow glacial for me. Then Chrome came out, with a much more rapidly updating Web Inspector, and I haven’t looked back. I far prefer Web Inspector to Firebug now and knowing that it’s built in as opposed to being the slowest Add-on in my arsenal has me all the more comforted by my decision.

Advertise here with BSA

The time has come where even the tools we use to mark up, style, script, and program are looking stellar; the designer in me is smitten. WebKit is by far the best of both worlds in that regard, and it really shines when it comes to things like the Web Inspector. Firebug really broke ground when it came to developing on the front end. It changed the way we all go about the process and streamlined things to no end. On top of that it’s helped us to optimize nearly every aspect of a page load and subsequent interaction.

When the Web Inspector first debuted it wasn’t nearly as feature rich as Firebug. In fact, the shipping version of Safari’s Web Inspector leaves a lot to be desired. When you read what’s arrived in the WebKit Nightly though, how can you not want to use it straight away? I’m not saying that Firebug is any less useful, but the changes (and the hotness) coming to Web Inspector are just stunning. I’m particularly fond of the changes coming to the Styles Inspection, DOM Inspection, Resources Inspection, and who can I kid; everything sounds supreme. Keep your eye on it.

More Web Inspector Updates

Advertise here with BSA

Safari has definitely come of age

Safari 3 was a leap ahead for the browser, and I loved (nearly) everything about it. WebKit is phenomenal, and we’re finding it implanted in more applications than ever. I was excited about all the changes going on with Safari 3 during the time of its initial release, and made an effort to use it as a primary browser. Not because I was looking for something different from Firefox, but the performance issues were a constant.

I did my best to try to beef up Safari 3 just enough to make it work for me. I stumbled upon Safari Tidy which is an equivalent to the HTML Validator Firefox extension which I’ve come to know and love. The plugin worked well, and there was a command line adjustment to enable a hidden Debug menu which provided an error console, WebKit’s Web Inspector, and a few other really useful tools. I only used the HTML Validator extension and Firebug in Firefox, so with these two modifications I felt it was fair to see if Safari could work for me.

Safari’s Develop Menu The Develop menu available in Safari 3.1

I quickly found that I had become extremely spoiled by Firebug. WebKit’s Web Inspector is really great, but the error console doesn’t really compare to the console in Firebug. Safari 3 was not the proper browser for me to use. That is, until Safari 3.1 was released. With the release of Safari 3.1, Web developers were provided their very own Develop menu which, I must say, is spot on with including the tools I make use of most often. Instead of providing a tool for everything under the sun, you’re provided a short list of Web development tools to make your life easier.

The Develop menu in Safari 3.1 summarizes very well the toolset I generally use most often in my work. Web Inspector continues to be an extremely valuable tool for both analysis and debugging in Safari. I was really excited to see integration with the browser window itself a la Firebug. The Safari Tidy plugin isn’t compatible with 3.1, but the error console has been given a bit of a boost and provides some insight regarding any markup errors in the document.

Overall, I think Safari 3.1 has really stepped things up a bit insofar as to include so many valuable tools out of the box. I think that with this release, a number of developers will prefer to work in Safari over Firefox.

How does Safari 3.1 compare to Firefox?

When comparing Safari 3.1 to Firefox 2, I may have found myself making the switch. Had it not been for the release of Firefox 3 beta 4, Safari may be the default browser for me. Firefox 3 beta 4 is a beautiful thing. While not recommended for general use, I’ve adopted it as my primary browser. The performance increase has been substantial and I’ve found myself waiting out delays much less frequently.

While the toolset included by default with Safari 3.1 will be exponentially helpful, I’m going to say that nothing compares to Firebug. Joe Hewitt‘s extension is essentially miraculous for Web developers sprawling the entire spectrum of talent. While still in beta, Firebug 1.1 is the only extension I’ve installed for Firefox, and it’s all I need. I don’t want to make it sound as though I’ve discounted Chris Pederick’s Web Developer extension (because it too is fantastic), but I’ve found that Firebug does anything and everything I need.

What truly sets Firebug apart from anything else for me is the JavaScript interaction capability it offers. Everything from error displays, to AJAX request logging, to JavaScript breakpoints, Firebug offers itself as a more powerful tool than anything I’ve seen. It’s helped me get through quite a bit of work that otherwise may have ended in disaster, and that’s the honest truth. Joe Hewitt has honestly produced a flagship tool for the entire Web design and development industry. It’s no surprise that both WebKit’s Web Inspector as well as the new Developer Tools provided in IE8 have taken a page out of the Firebug book both in form as well as function. Joe Hewitt set the bar for developer tools, and he set it high.

It’s Firefox 3 for me

I gave Safari 3.1 the spotlight for a solid week with production work. I tested it through and through with both basic site development as well as more detailed JavaScript work, and it was Firebug that brought Firefox 3 across the finish line first in my case. I was disappointed to seemingly miss out on the impressive speed of Safari as noted by many. I just didn’t see it. In fact, many times I would be able to launch Firefox and load a target URL before Safari nudged its loading bar. I’m sure it was a bit of a quirk somewhere as I’ve often read that Safari is extremely fast, but unfortunately it’s no speed demon for me.

At the end of the day, I’ll be sticking with Firefox 3 beta 4 as my primary browser, but Safari has truly proven itself as a fantastic platform for Web development.

Advertise here with BSA

The Mobile Web as it currently stands

The Mobile Web in and of itself requires a different mindset when designing & developing. For instance, while you’re still working with varying screen resolutions, they’re on a much smaller scale. With that comes an entirely new set of limitations that you’ve got to take into consideration with each piece of your design. Designing for a small screen is an adjustment similar to coming up with a style sheet the browser uses for print. It can be considered a limitation, but it’s possible to provide a functional solution at the end of the day.

Moving beyond screen resolution differences, there are also functionality differences when it comes to the Mobile Web. It is a challenge to ensure your designs are properly represented on the various Web browsers available for the desktop. Fortunately, it’s quite reasonable to have a testing environment in which you can test the vast majority of OS and Web browser combinations you’ll need to target. Unfortunately, this isn’t the case when it comes to the Mobile Web. There are countless handsets in production, each with a varying degree of Web “browser”. Some should not even be referenced as a Web browser, but that’s what they’re used for. I can’t begin to fathom what a test environment for every mobile device would look like. Point being, it’s very difficult to test for the majority of Mobile Web browsing environments.

There are also numerous usability concerns that should be taken into consideration. Many concerns have roots in the fact that a much smaller screen resolution needs to be kept at the forefront of thought. For instance, in-page navigation links become more of a convenience if used properly. The Mobile Web is not something I have extensive experience working with, but saying I’m excited to read Mobile Web Design by Cameron Moll is an understatement. From the website:

Much has been written about mobile devices. Much has been written about developing websites for the so-called “standards era” of the web. However, little has been written about the two colliding. This book aims to fill that void.

I can’t wait for the publish date.

So how does the iPhone fit in?

The iPhone brings to the table a feature that has been implemented before, but in my opinion on a much lesser scale. For those who aren’t aware, the iPhone provides a version of Safari specifically adapted for the iPhone. While it is technically the Mobile Web, it works to make the interaction as close to the desktop as possible. It achieves this by providing the same websites we see on a computer, but allows you to zoom in and out using a combination of finger taps and pinching in order to read page content. It’s really quite innovative, and will more than likely have many more people browsing the Web on a mobile device that otherwise wouldn’t have.

Previous mobile browsers have tried similar methods including server pre-processing in an effort to adjust the site design before it reaches your handset. The newly released Opera Mini provides functionality very similar to Safari on the iPhone, only without the touchscreen functionality. Personally, I haven’t had a chance to try either browsers, but I’ve heard good things about both. There was also a version of Opera meant for the Nintendo DS that included a ‘zoom view’ and ‘overview’ embracing the same idea; represent the entire design, but allow zooming to read content.

Other mobile handsets choose to apply any provided CSS with the media attribute set to "handheld". This is a completely different approach which is more or less ignored by the previous method. It is this set of handsets where your Mobile Web research will prove most useful.

The changes we can possibly expect

In my opinion, the iPhone does a fantastic job in providing access to the Mobile Web. The device removes many of the limitations of other Mobile Web browsers, and will be an attractive solution for many people. What’s interesting, is that even though you’re browsing the Mobile Web on an iPhone, the only considerations you’ve got to keep in mind are those you deal with when designing for the screen. The iPhone has brought the desktop Web to a mobile device. Does that mean we should no longer put thought into media="handheld"? Absolutely not. Simply because Safari on the iPhone is very advanced, you can’t discount all other devices and browsers. While many of the high end smart phones could very well adjust their implementation to be more like the iPhone, there will always be lesser powered devices that will not be able to perform at the level of the iPhone. As always, you should be mindful of usability concerns, graceful degradation, as well as accessibility guidelines.

Keeping this in mind, there are a couple things I do feel will change about the websites we visit on a daily basis. I think due to the fact that the iPhone is strapped to an EDGE network, many of the websites we visit often will begin to again take bandwidth and load time into consideration. While it’s a stretch to even suggest it, at the very least, site owners could see that a significant number of readers are viewing their site with an iPhone. While bandwidth should always be a primary concern with the Mobile Web, it hasn’t been a primary concern for many websites in my opinion. This effect may no be very widespread, but more prominent on websites with an audience of iPhone users.

Moving past bandwidth considerations

Beyond that, I truly don’t see the iPhone having a significant affect on the Mobile Web; it embraces too much of the desktop Web to make a huge impact. It can almost be compared to the release of Safari 3 on Windows in that the event has garnered a lot of attention, but the direct effect will be significantly less. What I do hope to see is an increased interest in the Mobile Web as a whole, not only for the iPhone, but by many manufacturers as well as developers. What do you predict?

Advertise here with BSA

Safari Available for Windows

I’ve read a number of articles that were written as a direct response to this event, a post by Mr. Hicks as well as a reaction from Mr. Snook, among others. While Mr. Hicks offers some intriguing questions, I found myself agreeing with much of what Mr. Snook had to say regarding this release.

He said that the release for Windows really doesn’t do all that much for developers working in Windows, with which I agree 100%. Safari uses WebKit, and Safari 2 uses a completely different WebKit than Safari 3, so a Windows developer getting their hands on Safari 3 isn’t doing anyone much good. The improvements implemented in WebKit are exponential in it’s current form when compared to the version used in Safari 2. If you’re looking to test using various operating system and Web browser combinations, it’s best to use them natively (or at least in a virtual machine) in my opinion.

It can’t be ignored what a big change it will be for Windows developers to be able to test in Safari, but in my opinion, this situation (when Safari 3 comes out of beta) will be very similar to the IE6/IE7 mixed distribution. While it will be nice for Windows developers to be able to test in one browser, it will still require a run-through in Safari 2 as well. As will happen with IE6, Safari 2 will eventually be overrun by Safari 3, but that will take quite a bit of time.

Will anyone really care about the release?

So if the release doesn’t help Web developers, will it have any sort of effect on the general population? In my personal opinion, Safari wasn’t ported merely to give Windows users a better experience on the Internet. It was ported because it was seen as a viable way to show Windows users the way of Apple. Many people refer to this type of thing as the iPod effect, iPod halo effect, Apple Envy, or some sort of variant. Hitting Windows users with an application they can use for free, an application they could theoretically use every day, is one more step for Apple in an otherwise Microsoft-oriented world. A Web browser can be a very personal choice for a person, and Apple wants people to choose them.

Firefox has been ridiculously successful in providing people a better way to browse the Web. Apple has seen this success, and in my opinion, feels it is now the best time to capitalize on the idea that Internet Explorer is not the end all be all Web browser for Windows users. It is their time to show that they’ve got a solution as well, and their solution has anti-aliasing in menus to boot. Let us not forget there are also snappy page loads, a small footprint, and that spiffy interface! Safari is an interactive advertisement for Apple, and porting it to the most widely used platform gives the application a very big stage to present itself.

The newest battle in the Browser Wars?

Personally, I’m a big proponent of open competition. If there are a number of high quality Web browsers openly competing to be the best, I think it will force browser manufacturers to provide the best product they possibly can, or else their user base will shift to a provider who can. A very large number of people have embraced Firefox as an alternative to Internet Explorer after it has proven time and time again to be a sub-par Web browser.

To this day I discover quirks and bugs that have continued to prevail in Internet Explorer 7. While it is a slight improvement over IE6, the entire Internet Explorer family of products is truly a sad state considering what is being released elsewhere. At the very least, it’s my hope that Microsoft starts to take their browser more seriously than they have, and the release of Safari for Windows will help to try and make that happen.

The true issue to keep in mind, however, is that the average reader isn’t going to care whether or not you were able to take your design to the next level because you didn’t have to worry about z-index bugs, the only thing that gets noticed is when things go wrong. Many of the drawbacks to Internet Explorer are not seen, heard, or cared about to many people other than Web designers and developers. What does get noticed is a better feature set, a cooler interface, and any performance differences that may be in place. Superior applications will reign supreme when it comes to that criteria, which will eventually decide a winner in any sort of Browser War.

Advertise here with BSA

One such product is WebKit, the open source Web browser rendering engine used by Safari (as well as a number of other products). It’s very important to keep in mind that Safari and WebKit are two very different things. Safari is a Web browser that uses WebKit as it’s rendering engine.

The WebKit developers put forth the effort to port WebKit to Qt, which is, as stated by the developers:

Qt is a comprehensive development framework that includes an extensive array of features, capabilities and tools that enable development of high-performance, cross-platform rich-client and server-side applications.

Qt is truly cross-platform and allows deployment on a wide range of hardware configurations, as opposed to other “cross-platform” products that are restricted to Windows and Mac OS X. The fact that the WebKit developers put forth the effort of porting to Qt4 gives users the ability to run their rendering engine on any platform. Thanks to their hard work, it’s quite easy to run a WebKit-based browser in Linux.

Preparing your Linux system for WebKit

I’d like to be explicit in saying that the following instructions are geared towards a fresh install of Ubuntu 7.04, but should be applicable to a wide variety of Linux distributions. First and foremost you’ll need to add extra repositories. After you have followed those steps we can begin.

There are a number of packages you’ll need to successfully build a Qt4 Web browser that uses WebKit.

sudo apt-get install libqt4-dev libxslt-dev gperf bison libsqlite3-dev flex build-essential subversion

There will be a lot of additional packages to install, so don’t be surprised if the list of packages for installation is significantly large.

Obtaining a nightly build of WebKit

Next, we’ll need to use Subversion to check out the WebKit source. The following command will check out files to a folder titled WebKit within your working directory, so be sure your working directory is appropriate (I used my home directory).

svn checkout http://svn.webkit.org/repository/webkit/trunk WebKit

You will be able to monitor the checkout process as each file is listed in your terminal.

The checkout will take some time, as there are quite a few files to download. When the checkout is complete, you’ll see the following message:

Building your Qt4 WebKit browser

When the checkout is complete, you can initiate the build of your Qt4 WebKit browser using the following command:

QTDIR=/usr/share/qt4/ WebKit/WebKitTools/Scripts/build-webkit

The script will take a minute to prepare the build, and then the process will begin.

This step can take quite a bit of time depending on your hardware configuration, so take a few minutes to have a cup of coffee and relax while your browser is being built. Your terminal will scroll with hundreds of lines of build commands and more, so don’t feel the need to sit and watch it build (unless you’re interested — I was).

When your build is complete, you’ll see the following message:

Running the browser

A successful build means you can run your Qt4 WebKit browser using the following command:

WebKit/WebKitBuild/Release/WebKitQt/QtLauncher/QtLauncher about:blank

A very basic browser window will appear with limited controls and an address bar. There will be some information scrolling in your terminal, but it can generally be disregarded.

You’ve now got a native WebKit browser to play around with in Linux. I took a second to attach the launch command to an entry in an panel using the WebKit icon. It’s more convenient than keeping the command saved somewhere to copy and paste when I’d like to test in WebKit.

You can also add your WebKit browser as an entry in your Applications menu using the menu editor if you prefer.

Some quirks I’ve come across so far

There are a few things that will appear out of place. First and foremost, you’ll notice that form inputs will have, what seem to be, a random background-color. I may be completely mistaken, but I haven’t looked into things deep enough to find the rhyme or reason behind the discrepancy. From what I can tell, if the input is styled with CSS, the style takes precedence over any ‘default’ colorization.

The next issue I’ve come across is that you’re not able to work with xHttpRequest. This is another issue I have not researched in enough detail, but if anyone has any insight regarding an inability to make use of XHR, I’d be interested in reading about it.

Finally, the only other quirk I’ve come across so far is that you’ll need to include http:// in any URL you enter in the address bar. While this may seem like a small detail to write about, after my first successful build I spent a few minutes thinking that something went wrong.

Things to keep in mind

Perhaps the most important thing to keep in mind is that you’re running a nightly build of WebKit, not the build Safari is using. The nightly versions are much more advanced than Safari’s WebKit, so some of the quirks that appear in Safari may be handled in your Qt4 browser.

Due to the version discrepancy, you can’t depend on a nightly build of WebKit sufficing for a legitimate test in Safari. It is useful, however, to take a quick look at overall structural elements of your designs before making the effort of moving to an OS X machine.

Footnotes and inspiration

I was originally drawn to working with WebKit on Linux by a post on the same subject at as days pass by. I had followed his instructions and ran into a few issues. Going on his advice, I joined #webkit on irc.freenode.net and started discussing a few issues with one of the developers there. He (or she) was extremely helpful in assisting me to successfully build WebKit. I was also directed to a Wiki page which included similar instructions to the post on as days pass by. I felt compelled to write this post based on specific instructions surrounding Ubuntu Feisty but would like to give much credit to the hard work of others.

Advertise here with BSA