A browser is more than script

Chrome released on Linux, and IE8 released from beta. Now people are beginning to question Firefox’s increasingly bigger piece of the blogger pie. Case in point, PC World.

Mozilla have several grand aims, and there’s much to be admired, but they’ve forgotten how to make a decent browser. I feel plenty of loyalty for them, because they’ve done more than anybody else to further the cause of open source software in the real world. But when I tried Chrome, as incomplete as it was, I realized I’d found a replacement for Firefox. As soon as it gets to beta under Linux, I will switch to Chrome. No question. It’s just infinitely better. It’s like when we all switched from Alta Vista (or Yahoo!) to Google back in the early noughties. The king is dead! Long live the king!

I was asked my opinion about the future of JavaScript applications this week, especially in light of the blazingly fast Chrome. I was rather surprised at the emphasis on JavaScript, because a browser is more than just a machine to consume script. A browser must also render a web page, as the designers built her; must display photographs accurately, hopefully using any photographer supplied profiles; to render the more complex SVG, in addition to the simpler Canvas; to handle complex file types, including video files, not to mention supporting different markups, such as XHTML in addition to HTML; to provide the utility to enhance the user’s experience, up to and including any extensions, such as the one I use to collect a page’s RDFa. Why, then, are we reducing the browser to nothing more than a device to to render HTML and JavaScript?

Firefox is working on its scripting engine, but it’s also been improving its graphical rendering engine, including adding in built-in support for color profiles, as well as improvements in support for CSS3 and SVG. Chrome has no support for color profiles, it’s graphical rendering engine sucks, as can be seen if you look at CSS3 curved corners in the browser, and it regularly fails my SVG tests. Try this SVG file in Chrome, but don’t blame me if your CPU spikes. Luckily, it seems that Chrome just aborts SVG files it can’t handle now, rather than fry the CPU. Then try the same page in Safari or Firefox; though both render the page slowly, they do render it—Chrome only rendered the file the third time through. It aborted the page the first two times. And the quality of the rendering? Well, see for yourself.

Look at my photos at MissouriGreen. Most use a color profile. Now, the photos look relatively good in Chrome on Windows, because I’m favoring a sRGB color profile to ensure maximum coverage, but if Chrome is ever implemented in the Mac, the photos will look plain, and washed out, as they do now with Opera. Not so the latest Firefox, and Safari.

Lastly, look at this site, or Just Shelley in Chrome, as compared to Safari, or Firefox, even the latest beta of Opera. I make extensive use of box and text shadows, as well as CSS3-based curved corners. No browser is perfect in its implementation of CSS3 curved corners yet, but the anti-aliasing in Firefox and Safari is vastly superior than what you’ll find in Chrome. I have noticed, though, that Chrome has improved its text and box shadows: it doesn’t plaster them half way down the page, now.

Why, then, do we talk about how “superior” Chrome is? And how Firefox is dying? When one looks at all of the browsers from an overall web experience, only IE8 is worse than Chrome.

I apportion blame for an over-emphasis on fast script over everything else equally between Google and the current HTML5 effort. I found it telling that, at the same time people are lambasting Firefox for “slowing” down, and praising Chrome for “speeding” up, Douglas Bowman is leaving Google primarily because the company relies on engineering practices, at the expense of fundamentals of design. One doesn’t have to stretch one’s intuition in order to see that the “machine” is also the emphasis in Chrome. But the same could also be said about the HTML5 effort: an emphasis on mechanistic aspects, such as client-side storage and drag-and-drop, at the expense of a more holistic environment, such as including support for SVG and ensuring continued support for accessibility—though I think this week, at least, client side storage has been pulled for inclusion…elsewhere.

Speed is important in a web browser, speed and efficiency, and Firefox isn’t perfect. Newer versions have been locking up on my Leopard machine, to the point where I now prefer Safari on the Mac. If I had to take a guess, Firefox has threading issues. It also needs to work on isolating extensions to the point where they can’t harm the overall browsing experience—or at least put something in place so that one knows certain extensions can adversely impact on browser performance.

At the same time, Chrome desperately needs to improve its graphics rendering capability. As this occurs, and as Chrome gets loaded down with extensions, I don’t think we’ll see the same fast speeds when rendering pages we see now.

It’s all a question of balance—the best browsers are the most balanced browsers, and sometimes this means slower page loading in support of better page rendering. As it is, Chrome, Firefox, Safari, and Opera are all giants towering over the anemic and disappointing IE8. If we want to talk about a browser “dying”, I have a better candidate in mind than Firefox.


Congratulations to Safari/Webkit

Congratulations to Safari/Webkit for being the first browser in the wild that provides a completely passing Acid3 test.

My own results:

[image no longer available]

I’m really getting excited by how much The Big Three (Safari, Firefox, and Opera) are improving, not only in standards support, but also innovation and application speed. It’s as if the web has suddenly shed its cocoon, unfurled glorious wings, and is ready to fly.


Future Firefox and color management

Before the build copy of Firefox (known as “Minefield”) upgraded itself on my Mac, dying a horrible and immediate death in the process, one other change I noticed in the upcoming version of Firefox is that color management is now on by default.

I also noticed, again before the crash and burn death, that the new version seems to be much more efficient and fast compared to the old.

As pointed out in comments, Bobby Holley has an excellent discussion on color management and the state of Firefox. Bottom line, in the interests of performance, the new version of Firefox will have color profiles turned on, by default, for “tagged” images: images with embedded color profiles. I started embedding profiles for my pictures about 2 months or so, ago, in hopes that more browsers will follow this path.

It would be nice to have full color management, but I think support for color profiles in images is a good interim solution. This is also the approach that Safari uses, and hopefully Opera, too, eventually.

Browsers HTML5

OMG! Web Developer has to wait! The Horror!

Where I focused on Ian Hickson’s statement about extensibility, every other person, and their brothers, sisters, and aunts are throwing a hissy because of the HTML5 timeline.

Scott Gilbertson writes:

Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?

Jeff Croft writes:

I’m not saying the specs should go away. They absolute serve a purpose. I’m just saying that I personally am done paying much attention to them. Instead, I’m reading blogs like Surfin’ Safari and Mozilla Developer News to find out what the new shiny is in browsers, because these are the things I can actually take advantage of in serving my clients and users.




Specification work was never focused on the end users, it’s focused at the user agents or others who have to implement the specifications. The Mozillas, Apples, Operas, Microsoft, et al. The only reason I pay attention to any of it is because of my concern about extensibility.

In the meantime, the new stuff that is HTML5 is leaking into browsers now, not years from now. That’s part of the specification process—actual implementation on the street in order to “proof the spec”, as it were. And pieces of HTML5 are not just showing up in Firefox, Opera, and Safari/WebKit— IE8 has a few HTML5 tricks up its sleeve.

Heck, HTML5 isn’t the only longish spec under development. CSS 2 started in 1998, the lost call for CSS 2.1 was in 2002, the candidate recommendation was in 2007, and Microsoft is only now providing CSS 2.1 support. That’s ten years, end to end.

In the meantime, I’m using CSS3 stuff that’s only supported by a couple of browsers, and the final release of all the CSS3 bits is probably years out, too. Of course, I only play around with my own spaces—professional web designers and developers know that we can’t necessarily use the shiny new stuff for client applications, because we’re still having to support browsers that are seven years old.

Hey! We’re still supporting browsers almost as old as the timeline when HTML5 will be finalized! I guess things aren’t as “today” and “now” as we think they are.

The point is, specifications take time, or at least, good specifications typically take time. Any doofus can toss a quick spec out and call it done, but who wants to use the doofus spec?

That schedule part of what Ian had to say didn’t phase me. As far as I’m concerned, the group can take as long as it needs. In the meantime, I’ll play around with the local storage, and some of the other odds and ends, as I keep putting in my annoying “But what about SVG?” “But what about RDF?” oar; probably helping to slow the development of the spec, even more.


Chromatic hyperbole

It would be impossible to miss the excitement over Google’s Chrome, though I would assume we would wait to actually see the product, first, before wetting our pants.

Yes, Google entering the browser marketplace is news, but some of the things I’ve been reading are, well, frankly asinine. For instance, Computerworld breathlessly writes, Google’s Chrome aims to kill Windows, make Web the OS of choice. A bit hard, wouldn’t you say, when Chrome requires Windows just to be able to run?

Let's kill off Windows with our Web OS.



Well, Windows is dead.

That's great! 


Uh, where's Chrome?

Well, you see...

Do we also need to remember our concerns about Google? You know, the whole privacy thing? Or are we a modern day bunch of Pavlovian dogs, trained to drool on cue whenever Google is involved?

There are issues associated with this browser, babes. First of all, as great as it is that Google is using Webkit for its infrastructure, it’s also coming out with its own JavaScript engine. My first question is: is Google going to conform to standards? Or is it going to go its own little way, and just assume we’ll tag along? Then there’s the issue of the engine being multi-threaded—and here I thought Photoshop was going to be the only pig on my system.

My concerns aren’t just related to JS. As I read somewhere—who knows where—we can now see why Google is footing the bill for Ian Hickson to head up the HTML5 effort. However, now that Google is “one of the browser competitors”, how will this change the dynamic in all these standards groups? I’m not going to necessarily give HTML5 over to Google to define to its own Chrome standards. I imagine that some of the browser companies would feel the same.

And about those privacy concerns…exactly what kind of information is Google going to be collecting about us as we use the damn thing?

Frankly, I’m all for anything that weakens the abysmally tenacious hold IE6 and IE7 have on desktops, but I’m not sure yet another player in the field is what we need. Especially a player who, frankly, exhibits many of the same tendencies towards arrogance, as well as interest in complete dominance, as the company they supposedly “hate”. I can understand Google’s impatience with the other browser companies—but Google also has a tendency to act impulsively, and leave the rest of us to pick up the pieces.

As for web applications taking over the world, we’re just now starting to hit against issues of broadband caps, not to mention the problems we’ve had with centralized services recently. Does Twitter ring a bell with you folks? How about Amazon’s S3? GMail? In the last month, we’ve seen outages at a considerable number of centralized web services, and we haven’t even started putting our critical operations into “the cloud”.

Do you really want your business to hit a stand still because you’ve lost your internet connection, hit a broadband cap, or “the cloud” is not playing nicely at the moment? Seriously?

Look, yes. Get interested, yes. Peer around under the hood, and take it for a spin, most definitely yes. But get a grip–the web world as we know it hasn’t suddenly come to an end just because Google has decided it wants to play the browser game, too.

Downloaded. Installed. Works fast. Chrome doesn’t work on the Mac. Thanks to WebKit it does support XHTML and SVG. However, I’ve hit an odd rendering error for this page, which I don’t get with my nightly WebKit download.

Matt Cutts did respond to privacy concerns about Chrome, though I wish he wouldn’t categorize these concerns as being the paranoid ramblings of conspiracy theorists.