rc3.org

Strong opinions, weakly held

Tag: browsers (page 1 of 3)

On Google Chrome and other browsers

Tim Bray wrote up the browsers he uses on a daily basis. Impressively, he uses Google Chrome, Firefox, and Safari consistently.

These days, I’m using Google Chrome for most things and Firefox for Web development. I’m hooked on Firebug and I like doing development in a browser that’s sequestered from the browser I’m using for email and standard Web surfing. Unfortunately, Firefox loses the basic speed test to Google Chrome, so I can’t use it for day to day browsing. If I were going to put up with a slower browser, I’d stick with Safari because it is a better behaved OS X application.

Like Majd Taby, I have various nits to pick with Google Chrome, but I’m using it for most everything these days. In the end, speed is the key. It renders Web pages very, very quickly. My biggest problem with it is that Google Chrome hangs a bit when you click on a link and then click on a different link on the same page in hopes of hijacking your original request and going somewhere else.

Until recently, I was using Safari for my day to day browsing. I love it as an application, but the speed difference with Google Chrome is noticeable enough to lure me away. I do still use Safari in a standalone Fluid app to read my work email (a Google Apps account) in its own application window with an unread email indicator in the dock.

It wouldn’t surprise me if Safari took another big leap forward soon and I went back to it. For whatever reason, I’ve found Firefox to be consistently uncompetitive with Google Chrome or Safari for a long time, but I’d be happy to use it for everything if they can catch up with the WebKit-based browsers.

Whenever I look at software markets with healthy competition, like the browser market, or the market for smart phone platforms, or the market for Web application platforms, I can’t help but think about the opportunity cost of the Microsoft desktop computing monopoly in the nineties. How much better would word processors and spreadsheets be had Microsoft had a real competitor for Office? How much better would desktop operating systems be had they faced real competition in that market?

URL Literacy

Jono from Mozilla makes a great point that most people (including me) have completely overlooked when it comes to the Web — most people don’t really understand URLs:

So what this mess teaches us is that there are lots of people out there who don’t know how to read a URL. The URL in the location bar, if they notice it at all, must appear to them as nothing but a bunch of computer gibberish.

Think about it from their point of view. They knew that Googling “facebook login” and then clicking the first link took them to their Facebook login. I wouldn’t call it the best way of getting to Facebook, but it was obviously working for these poor souls. Until one day, they saw something they didn’t expect. If you don’t know how URLs work, then all you know is that your expected Facebook login page has somehow been replaced with… something else.

The whole blog post is really thought provoking and worth reading for anyone who designs or develops software. For those of us who have completely internalized URLs, it’s hard to empathize with people who see getting to Web sites as a series of steps they follow. At this point it doesn’t matter whether people access all the Web sites they use through Google or some other search engine, other than to figure out how to make things better for people who use the Web that way.

I wonder whether browsers could display URLs in a way that makes things easier for users. The most important thing about a URL, especially in terms of preventing fraud, is the domain name — the real one, not the fake one that’s included to defraud people. Maybe it should be highlighted in some way with the owner of the domain displayed as well.

Via Simon Willison.

The real end of IE6

Web developers have hated Internet Explorer 6 for a long time. If you design Web sites or write Web front end code, you know all too well how much work it is to support IE6 on all but the simplest Web sites. What we’ve recently learned is that IE6 is much more insecure than its successors, and now Microsoft admits that IE6 has security holes that they cannot fix.

Getting rid of the last vestiges of IE6 is going to require a three pronged attack. IT departments that still require it are going to have to be educated on the security risks of sticking with it. Or, more likely, the executives who have the power to tell the IT department what to do are going to have to be educated. I imagine that in the near future, we’re going to see a lot of IE6-remediation work. Web applications that support only IE6 are going to have to be upgraded so that IE6 can be abandoned.

Users who haven’t upgraded due to indifference are going to have to be made to suffer. Web sites need to start dropping support for IE6. When sites like Facebook and YouTube no longer support IE6, those users will upgrade Internet Explorer or find another browser.

And finally, Microsoft is going to have to take more steps to induce users to upgrade. Microsoft has waffled on phasing it out completely to placate companies with applications that depend on IE6, but it seems like today is the day that policy has to be revised.

Competition breeds innovation

Firefox 4.0 will include a feature that runs the browser in multiple processes, like Chrome:

Electrolysis is the name of a Mozilla project that will split Firefox into multiple processes — one for the user interface, one for plugins and one for each tab. Similar functionality is already being seen in other clients, like Google Chrome. Like Chrome, a crash in a single tab will no longer be able to bring down the entire browser. Also, we can expect Electrolysis to make Firefox faster and more stable overall.

Google Chrome Frame

Google has thrown their hat into the ring when it comes to dealing with the Internet Explorer 6 issue, creating an IE plugin that replaces the IE rendering engine with Chrome. I think it’s a pretty brilliant idea, but I’ll be curious to monitor the adoption rate. My guess is that people who are stuck using IE6 for whatever reason won’t install the plugin, given that they haven’t installed any of the other excellent, free options that currently exist. It does let Google take another step away from supporting Internet Explorer, though, since now they can demand that users install the plugin.

HTML 5/XHTML 2 link roundup

This is a special link roundup related to the W3C killing off XHTML 2 and putting all its eggs in the HTML 5 basket. I’ve posted about this myself here.

Links from July 9th

Google Chrome OS is vaporware

John Gruber points out that Google Chrome OS is vaporware. There’s no running code, there are no devices, and there aren’t even screen shots. He asks but doesn’t answer why Google made this announcement right now. Steven O’Grady punts on this question in his analysis as well.

This is the burning question for me, why now? In the olden days, we’d call this FUD. There are not many reasons to announce something so early. One is that it was about to leak, and Google wanted to get its story on the record before the media took off with the story. The other is manipulation (FUD). You announce something early to keep people from making decisions without taking your future plans into account.

Right now the market share of the Chrome browser is small. That gives Google little juice in terms of demanding a seat at the table in discussions of future browser development. Google may be trying to raise the prestige of Chrome by letting people know that soon there will be computers available which will support Chrome and only Chrome for browsing. If people presume that Chrome OS will be successful, then suddenly it becomes much more important to take Chrome into account in the overall browser market. So that’s my guess: Google is announcing Chrome OS so that more people will take Chrome seriously.

A new way of writing a standard

I’ve been paying attention to the various goings on in the world of markup this week, and there will be lots of relevant links in the next roundup I post, but I wanted to comment on this email from Shelley Powers on Ian Hickson’s decision to give every browser maker veto power over any of the features listed in the HTML 5 specification. Powers absolutely hates this idea, but I confess that I’m intrigued.

Hickson has decided that the spec will not contain any features that browser vendors have not committed to support. This is very different from the usual standard-writing process, especially when it comes to W3C standards. In the past working groups have come up with lots of exciting new features and various rules to be obeyed and then the programmers go off and create something loosely based on that standard. The degree to which browsers are compliant with recent standards is a running joke, although things are much better now than they were a few years ago.

When asked whether each browser vendor can, by themselves, prevent a feature from being included in the HTML 5 recommendation, Hickson responds:

Not immediately, but if you had notable market share and we could not convince you to implement these new features, then yes, I’d remove them and then work with you (and everyone else) to try to come up with solutions that you would agree to.

Even if you did not have notable market share, I would work with you to understand your objections, and try to resolve them. (Naturally if your goals are substantially different than the WHATWG’s goals, then this might not go anywhere. For example, if Microsoft said that we should abandon HTML in favour of Silverlight, without making Silverlight backwards- compatible with HTML, then this would be somewhat of a non-starter, since backwards-compatibility is an underpinning of our work.)

What I find interesting about Hickson’s approach is that he makes the presumption of good faith. His process will only work if the browser vendors wish to collaborate to improve the Web experience by adding new features to HTML 5. Powers objects because she assumes bad faith on the part of vendors:

If we continue to allow one vendor/one veto to be the underlying philosophy of the HTML WG, then we might as well end working on it at this point, because I can’t see it being anything more than a race to the bottom, with each vendor looking to cripple open web development in favor of its own proprietary effort.

Worse, this process completely and totally disregards the community of users, of web developers, web designers, accessibility experts, and gives ultimate power to five companies: Google, Apple, Microsoft, Mozilla, and Opera–with Microsoft having the largest veto power. The rest of us might as well go home, because we have no say, no input, nothing of value to add to the future of the web. Not unless we crawl on bent knee to each vendor and ask them, “Please sir, I want some more.”

So here’s what I like about the Hickson philosophy. It will expose whether browser vendors want to work together to build new things everyone can benefit from, or if they want to rekindle or perpetuate the browser war. The thing is, we’ll know it earlier in the process than we would otherwise. Powers proposes a “three vendor” standard — if three vendors promise to implement a feature, it will be included. But then what happens is that the features go into the spec, those three browser vendors implement the feature, and the intransigent vendors do not? As professionals we can’t use new features anyway until they’ve been implemented. Under Hickson’s approach, the inclusion of a feature in the recommendation signals a commitment from all browser vendors to implement. We can plan ahead based on that.

If nothing else, it’s a new approach to an old problem. I’ll be curious to see what the process yields.

Links from June 17th

Older posts

© 2024 rc3.org

Theme by Anders NorenUp ↑