Technology Tales

Importing bookmarks into Firefox

Moving from one operating system to another like I have means that a certain amount of migration is in order. While I have already talked about migrating my email, there are lesser acts too. One of these is carrying across bookmarks into the new world. This should be an easy thing to achieve and, for the most part, it is. However, the Import... entry on the File menu of the main browser only brings in bookmarks from other applications. To get more flexibility, you need to open up the Bookmarks Manager window from the Bookmarks menu (Organise Bookmarks... is the entry that you need). The File menu of the Bookmarks Manager has entries named Import... and Export...; their functions should be very apparent. The former will read from a file, very useful if you do not want to disrupt what you already have. Another migration option is the potentially disruptive act of copying in an alternative bookmarks.html file into your Firefox profile folder and overwriting the one that's already there.

Firefox spell checking: getting rid of a mispelling from your dictionary.

Mozilla Firefox includes a spell checker and, like any such function, it offers a chance to add words to a custom dictionary. Of course, you can also add misspellings too, and these definitely need to be removed. With Word, it's a matter of looking for custom.dic and deleting the nefarious item. With Firefox, it's similar, at least on Windows anyway. The file that you need to edit is persdict.dat which you'll find it in C:\Documents and Settings\[user name]\Application Data\Mozilla\Firefox\Profiles\[random name].default. My search for the relevant information took me over to Lifehacker.

Update 2012-12-11: For users of Linux, the location of the above file is as follows: /home/[user id]/.mozilla/firefox/[random name].default. Once you find persdict.dat in there, the required editing can be performed.

Missing borders in Internet Explorer

It's quite difficult to describe this observation in a title so here goes with a longer description in a post. One thing that I spotted with the Prosumer theme used on this blog is that the links on the horizontal navigation bar underneath the mast head were not appearing as they should. The links have been formatted using CSS to appear in boxes with borders that are more apparent when you hover over them. In IE, the top and bottom borders were missing. After a spot of digging, I came up with the line-height property being the cause, and I was right: the extremities of the boxes surrounding the text were being cut off because they exceeded the allotted space. As if to emphasise that IE7 isn't as major a leap forward from IE6 as we would have liked, the problem affected that browser as well.

Aside: Link text colours weren't being honoured by IE7 like they are by IE6, Firefox and Opera, so another tweak to the CSS was needed.

CSS Control of Text Wrapping

Recently, I spotted a request for a dropdown list like that which you see below. I managed to create it using the CSS, but it only worked for Firefox, so I couldn't suggest it to the requester.

form select, form select option {width: 185px; white-space: normal;}

form select {height: 16px; width: 200px; white-space: normal;}

form {margin: 300px auto 0 auto; width: 300px;}

Here's how it looks in Firefox 2:

And in IE6:

And in Opera 9:

It would be nice if the white-space attribute gave the same result in all three but hey ho... As it happens, the W3C are working up other possible ways of controlling text wrapping in (X)HTML elements, but that's for the future, and I'll be expecting it when I see it.

For menus with wrapped entries, using DHTML menus and DOM scripting seems the best course for now. I suppose that you could always make the entries shorter, which is precisely what I tend to do; I am pragmatic like that. Nevertheless, there's never any harm in attempting to push the boundaries. You just have to come away from the cutting edge at the first sign of bleeding...

Of course, if anyone had other ideas, please let me know.

FCKEditor for WordPress

Because the standard WordPress post editor got broken on this blog, my mind turned to replacing it, especially when I spied plugins for adding FCKEditor to the thing. Dean Lee's is the one that I am using, and it seems to work well so far too. As this is FCKEditor, there are more editing options than those offered by the WordPress standard and that's even with the advanced options made visible with the Alt+V/Alt+Shift+V keyboard shortcuts; the former is for IE and the latter for Firefox. We'll see how it goes from here...

IE6 and JavaScript performance

Having been exposed to an application at work that uses a lot of JavaScript, I fully appreciate what some mean when they discuss IE6's inefficient handling of JavaScript. After seeing a web page taking an age to reload and your CPU taking a hammering because of JavaScript processing, the penny does tend to drop...

Needless to say, this very much impacts the world of AJAX-driven web applications with their heavy dependence on client-side JavaScript. While IE7 does come to the rescue, there remain plenty of IE6 users still out there, and this is reflected in website statistics. This demonstrates a certain level of inertia in the browser market that not only afflicts the uptake of IE7 but also the likes of Mozilla, Opera and Safari. It also means that anyone developing AJAX applications very much needs to continue testing in IE6, especially if the product of their labours is for wider public use.

An example of such an application is Zimbra, an open-source web application for messaging and collaboration, and the people behind it have generously shared the results of their browser performance benchmarking. They did comparisons of IE6 vs. IE7 and Firefox 2 vs. IE7. IE6 easily came out as the worst of these, while Firefox 2 was the best.

The next question to be asked could centre around the type of code that is processed inefficiently by IE6. While I wouldn't be at all surprised if a list emerged, here's one: using Microsoft's proprietary innerHTML object to update the DOM for a web page format. Having a quick trawl on Google, this came up for mention as a cause of memory leaks. It is also a Microsoft innovation that never got taken up by those overseeing web standards, hardly a surprise since a spot of DOM scripting achieves the same end. It may be faster to code than any alternatives, and it does have some support from other browsers, but it does seem to have got a bad name, so it should be avoided if possible. That said, it would be interesting to see a performance comparison between innerHTML and DOM methods in IE6.

The return of the Navigator

With the launch of the ill-fated Communicator, Netscape dispensed with the Navigator brand that had served it so well up to that point. And it continued the practice when it turned to re-branding the output from the Mozilla project. The new Navigator is, in essence, a tweaked variant of Firefox's latest incarnation and has the spelling checking capability that I have been missing when giving Safari a spin. You have to ask why, and I am not certain that I have the answer. That said, it does feel slick and works well, a definite change from some of it predecessors then.

Safari on Windows?

Steve Jobs recently surprised an audience at Apple's Worldwide Developer's Conference with the announcement that the Safari web browser is being made available for Windows. While everyone else is awaiting Apple's forthcoming iPhone, the Safari announcement is a more important one to me; not being big on phones, I will let the iPhone excitement pass me by. Without either buying a Mac or running OS X in a virtual machine, there was no other way for me to test my web pages in Safari bar looking for a rendering site on the web. Now, that has all changed, and I have downloaded the beta to have a look; it should iron out any rough edges that Mac users have been seeing.

Update: Safari seems to have got a mixed reaction from Windows users; some have tried it with Vista and cited issues. Another gripe has been its memory footprint, but I have seen Firefox take up 100 MB.

WordPress 2.2

WordPress 2.2 made its debut yesterday and, after a spot of cautious testing, I upgraded my hillwalking blog to use it. The reason for the testing was that self-hosted WordPress blogs can now have what WordPress.com blogs have had for a while: built-in widget capability. It was this that upped my level of caution, but the changes weren't as drastic as I had feared: you need to amend your theme for widgets to be supported, and not having done this causes no untoward effects. Making themes widget compatible is something that Automattic describe in a helpful article on their website. Other than this, WordPress 2.2 doesn't cause much upheaval and, apart from pieces of JavaScript snagging on occasions in Firefox, all seems well. I am still sitting on the fence as regards those widgets, though...

Wonders of the middle mouse button

My installation of Firefox seems to have stopped listening to the target attribute of hyperlinks. Thankfully, the middle mouse button comes to the rescue. Clicking on a link with the middle button opens it the destination page up in a new window or tab, depending on how you set your defaults. The behaviour goes even further than this: the trusty middle mouse button does the same for bookmarks and the Google search bar; all very useful. And it is not just a Firefox thing, either. IE7 does the same thing for web page hyperlinks and bookmarks while in Opera, it is limited to links on web pages.