However, Chrome offers a lot of promise.  According to marketshare.hitslink.com,  Chrome seized 0.78% of the worldwide browser share in less than a month on the scene, a phenomenal achievement. If the Google staff commits to really developing it, with full plug-in capability, solidness in handling intensive Flash-based Web apps. and fixing the long-standing problems with WebKit (such as the alternate stylesheet issue), Chrome will undoubtedly go far.  (Unfortunately, it will also probably go far if they do nothing and leave it at version 0.2 for three years. They’re Google, after all.) I really do want to see the Web improve and browsers improve, and Chrome can offer a lot.

However, this morning I test-drove “Minefield,” the development codename for Firefox 3.1, and I’m amazed. In my not-so-humble opinion as a Firefox fan, Firefox’s sole problem has been its speed. Minefield fixes that with blazingly fast page downloads and a new Javascript rendering engine which “may be the fastest on the planet.”  Kudos to the Mozilla team!

Initial reactions:
Chrome is fast. Very fast. The difference is especially noticeable on high-bandwidth connections. (On my DSL connection at home, it’s fast, but not breathtakingly so.)

Chrome uses multi-threaded rendering so each process called for in any Web page or Web app is treated independently. In other words, an infinite Javascript loop won’t cause everything else to stall while waiting for it to complete. What’s more, each tab’s processes are independent of the other tabs. Essentially, each tab is a separate instance of Chrome, and should any tab freeze, it will have no impact on any other tab. A convenient shortcut in case that should happen, is that you can right-click on the title bar and immediately go to Task Manager and close the troublesome tab individually. Tabs can also be dragged-and-dropped out of the main window.

At first, I thought, “Great, Chrome is nice, sleek, and fast, a great Web-surfing tool, but only Firefox has what I need for development.” Well, I was wrong. The “Inspect Element” feature of Chrome (accessed by a right-click) is like a simplified, more intuitive Firebug, combined with the best of Aardvark and most of the best of the Web Developer Toolbar. CSS infomation can be seen for every single element, including default styles and declared styles, and you have the option of showing inherited styles as well. In addition, styles that are overruled are indicated as such by a strike-through, and every declared style affecting the element has its precise location shown.

“Metrics” gives a diagram of the box model on any block-level element, with the rendered padding, border, and margin in pixels. If you select the Resources button and reload the page, it will generate a beautiful chart listing every file loaded and diagraming when it began and finished loading with its order in the entire assembly. The HTML is also be automatically validated. The flip side: The “Size” button is entirely non-functional. No file size or image dimension info is available. Also,there’s nothing that has the functionality of the “Edit CSS” option of Firefox’s Web Developer Toolbar. I miss the capability of a simple right-click to view background images.

Yet overall, Chrome’s development tools are impressive and eminently usable even at this initial level.

A few aberrations in Chrome’s behavior have been noted. Chrome doesn’t like Facebook much. For instance, clicking on “Join this group” simply refreshes the page. Also, apparently Chrome misbehaves regarding some alternate stylesheets. It doesn’t with the alternate stylesheets on my other site, so I’m not sure what is the exact syntax that triggers it.

As a diehard Firefox user, the lack (thus far) of any plugins for Chrome is a definite minus. Different people will have different gripes, but here are mine:

1. Chrome is ugly! Please let me skin you!
2. I really, really, really want to be able to use my del.icio.us bookmarks in a sidebar.
3. Edit CSS and a quick-and-dirty View Background Image, please.

I thought another gripe would be not being able to change search engines in a single click as with Firefox, but with a wonderfully simple and quick hack, you can actually switch search engines faster in Chrome.

Chrome uses the same box for searches and typing URLs. To work with other search engines, right-click in the location bar and choose “Edit search engines…” If you simply want to make a different engine your default search tool, select the “Make Default” option. But it you want to be able to switch to a different search engine on the fly, click the “Edit” button and abbreviate its keyword. On my computer, I abbreviated yahoo.com to just “y,” and amazon.com to “am.” To instantly change the search engine, just type the keyword, a space, and your search term. This is actually much faster than selecting the desired search engine from a dropdown box as in IE7 and Firefox.

It’s an interesting concept, and I don’t want to go back to the days when a copy of Netscape Navigator 1.22 fit on a single floppy disc, but Pogo seems way too far ahead of its time in terms of realistic user resources. And just when you thought 2 gigs of RAM was enough… Pogo!

• deviant box model
• DOCTYPE switching
• no min- or max- widths or heights
• no variable-opacity PNG support
• no SVG support
• inability to serve XHTML as application/XML

and the sad list could go on. Many of these faults have been addressed and corrected, but increased support has been incremental, over the last six or seven years. However, earlier this year, Microsoft announced that IE 8 passed the Acid 2 test, an important demonstration of supporting most key CSS properties. Yesterday, they made that good news quite a bit sweeter, by announcing that the default rendering mode for IE8 will be with their highest support of standards, which reversed a previous plan requiring designers to include special code in their pages to trigger IE8′s standards rendering mode.

See also Microsoft’s announcement.

Earth to Apple: you’ve got some work to do.

On their download page, Apple touts the many advantages of Safari for Windows, although most of them are advantages only over the rapidly diminishing Internet Explorer 6. However, the top of the list promised that Safari would be, hands-down, the fastest browser. Well, it is. It’s amazingly fast. It also handles Flash exceptionally well. I tested it on some very Flash-intensive sites, e.g. marinewebservices.com and truckwebservices.com, and pages flew in, particularly when compared to Firefox, which seems to struggle with Flash in large quantities. (Flashblock is one of my favorite Firefox extensions.)

But the speed comes at a cost. Windows Safari’s CSS rendering is a shambles compared to its brother on the Mac. Positioned divs overlap each other unpredictably. CSS-based slideshows don’t work. I was curious how it would perform on the Acid2 Test, since Safari for Mac earned well-deserved fame for being the first to pass it. As you can see from the screenshot, it rendered the test image slightly better than Firefox 2, but not by much. Something is clearly wrong with Safari.

I might make a more detailed inventory sometime, but for now, all I can say is another broken browser is not what Windows needs.

C’mon Apple. Keep doing what you do best… iTunes, iPod, iPhone, and … what’s that computer you specialize in? Oh yeah, the Mac. Nice job, that.

Warning: You are viewing this page with an unsupported Web browser. This Web site works best with Microsoft Internet Explorer 5.01 or later or Netscape Navigator 6.0 or later. Click here for more information on supported browsers.

The funny thing is how much I’ve come to agree! Almost anything done imaginatively or creatively with CSS will fail in Internet Explorer 5.0, 5.5, or 6.0. I now code for Mozilla first, then progressively “dumb-down” my CSS for IE versions with the ridiculous hacks and workarounds needed to do what Mozilla, Netscape 7, Opera, Konqueror, and Safari do naturally most of the time.

The frosting on the cake was when I clicked on on the upgrade link, a slightly lengthier message appeared, politely recommending I upgrade to the current version of IE or Netscape and providing links. Microsoft kinda-sorta recommending upgrading to Netscape 7.1? That’s good advice for anyone! Nice to know that even Microsoft’s web designers have problems with their flawed browser. And next time, guys, why not include links to Mozilla, Opera, and Safari?

So it began. I searched everything I could for information on this bug, from CSS books, to my favorite CSS sites, to Google searches with every combination of keywords I could think of. Nothing! Nothing I had read could account for this. I tested other stylesheets in my preferred layout. Some broke, some didn’t, and the ones which broke, broke in different places!

So my layout wasn’t buggy, but by now, I was going buggy! At least I could concentrate my search for the bug in the styles rather than the structure. The worst one was the Forest stylesheet (which is the default index page on my personal site.) I had noticed from the beginning that the problem was worse the smaller the window became—the “magic” points were closer together. Finally, I realized it was related to word-wrapping in some hyperlinked movie titles in my most recent post. I tried using Microsoft’s “word-wrap” property, which helped nothing. At odd points, when these italicized hyperlinked words wrapped down to the next line, the content DIV would fall away. Italicized words. (I may be one of the few designers who actually uses the recommended CITE tag for titles, and CITE renders as italics by default.) Not expecting anything, I typed “IE CSS bugs italics,” and found

the page that explained everything».

Italics! How could the bug be italics? Every word processor in the last 20 years has handled italics. as has every Web browser from Netscape 1 on. How could Internet Explorer 6 mangle them? (Answer: it mangles them effectively as it mangles many things.) Sarcasm aside, IE panics when calcuting width for italics in boxes that are beside floats. This is a nefarious problem that seems to be almost unknown compared to, say, the Box-Model bug. Nefarious, because when can you guarantee that your client will not need italic text, maybe a LOT of italic text, whether it’s an extended quote, a long title, or an emphasized sentence? Understanding this potential layout-destroyer should be as well understood as float bugs and box-model bugs.

There is a fix, and it’s not as simple as styling CITE and EM as “font-style:oblique,” (which doesn’t work, in case you were wondering, the bug affects anything with a slanted type). Bruno Fassino explains all that is known about it at this time on a page at the Position is Everything page. My very brief explanation of the fix, which follows, is no substitute for his lucid work, but I think more pages explaining this are desperately needed.

The key is to add styles to the lowest-level block element which contains the italic text. This will almost always be either a P, DL, UL, OL, BLOCKQUOTE, or DIV tag. Often it’s a direct parent, but sometimes, as in the case of my CITE tags within A tags, the lowest-level block is a grand-parent or higher. The styles must be visible only to Internet Explorer for Windows, and not only that, but there are two mutually exclusive stylings needed, one set for IE Win 5.5+, and another for IE Win 5.0.

IE 5.0 Win must make the width of the containing block 100%, and give it the overflow:hidden style. IE 5.5+ Win must give it an auto-sized width, a minimal height, and visible overflow. The stylesheet snippet below hides it from all non-IEWin browsers, and feeds the corrected styles to the proper versions of IE rather painlessly. For details, see IE and Italics Problem» at Position is Everything.net.

/* \*/
* html p, * html dl, * html ul,
* html ol, * html blockquote, * html div {
         overflow: hidden;
	 overflow: visible;
	 width: 100%;
	 width: auto;
	 height: 1%;   }
/* */

An alternate solution would be to use IE Win’s conditional comments in the HTML. Peter Paul Koch at Quirksmode» makes an excellent case for using conditional comments rather than parser hacks. I sometimes use them, but sometimes prefer to put them in the stylesheets—they don’t mix well with stylesheet switchers, for instance.