While you can use <br /> tags, there is another way to achieve similar results: the &nbsp; or non-breaking space entity. Put one of them between two words and you stop them getting separated by a line break; I have been using this in the latest design tweaks that I made to my online photo gallery. Turning this on its head, if you see two words together acting without regard to normal wrapping conventions, then you can suspect that a non-breaking space could be a cause. There might be CSS options too but their effectiveness in different browsers may limit their usefulness.

I recently changed the engine of my online photo gallery to a speedier PHP/MySQL based affair from its PHP/Perl/XML powered predecessor. On the server side, all was well but a peculiar display issue turned up in Internet Explorer (6, 7 & 8 were afflicted by this behaviour) where photo caption text on the thumbnail gallery pages was being displayed erratically. As far as I can gather, the trigger for the behaviour was that the thumbnail block was placed within a DIV floated using CSS that touched another DIV that cleared the floating behaviour. I use a table to hold the images and their associated captions in place. Furthermore, each caption was also a hyperlink nested within a set of P tags. The remedy was to set the CSS Display property for the affected XHTML tag to a value of "inline-block". With a cascade of DIV, TABLE, TR, TD, P and A tags, finding the right tag where the CSS property in question has the desired effect took some doing. As it happened, it was the tag set, that for the hyperlink, at the bottom of the stack that needed the fix. Of course, it’s all very fine fixing something for one browser but it’s worthless if it breaks the presentation in other browsers. In that vein, I did some testing in Opera, Firefox, Seamonkey and Safari to check if all was well and it was. There may be older browsers like versions of IE prior to 6 where things don’t appear as intended but I get the impression from my visitor statistics that the newer variants hold sway anyway. All in all, it was a useful lesson learnt and that’s never a bad thing.

I have encountered something very strange with my hillwalking blog and I have to admit that am at something of a loss as to how to resolve it. Opera (version 9.x), it seems, is not displaying the date corresponding to the first post of a particular month. You can see the effect at the right for the current month and, yes, the tenth of the month has a post associated with it. What compounds the mystery is that the same issue doesn’t affect this blog so some further investigation is very much in order. However, the cascading element of CSS doesn’t help much when trying to track down the cause of this sort of thing. While, it’s irritating, I don’t have any definite answers yet and so would appreciate some suggestions. In the meantime, I’ll be staying on the lookout for a fix. Curiously, all’s fine on Firefox and IE.

I have seen a web application that displays thousands of records in a scrollable table (please bear with me, there is a very good reason for this). from the appearance of the table, it would be reasonable to assume that the table is generated by the server and output directly to the screen but this isn’t the case. What actually happens is that the server more or less outputs JavaScript code that is then executed. This takes the form of large arrays that are slotted into the DOM as the contents of the required table by a JavaScript function. With the large amounts of data involved, this means that the browser fully loads the client CPU while the JavaScript processing takes place, something that takes up to a minute to complete. Admittedly, the browser is IE6 but this was all on a PC with a 2.53 GHz Pentium 4 and 512 MB of memory. Getting the server to deliver standards-compliant (X)HTML for what is needed in the first place seems a much, much better approach to me.

Here’s a piece of code that should really be unnecessary when you put the favico.ico into the root of your website directory:

<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />

The favico.ico should automatically appear there and in your browser bookmarks (favourites in IE) but there are occasions when the above has to sit in the header section of your web pages. I know because I am doing it for this blog.

Having been exposed to an application at work that uses a lot of JavaScript, I fully appreciate what some mean when they talk about 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 of client-side JavaScript. While IE7 does come to the rescue, there remain plenty of IE6 users still out there and this is reflect in website statistics. This reflects 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 share 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 in these while Firefox 2 was the best. I suppose that the next question to be asked centres around the type of code that is processed inefficiently by IE6. I wouldn’t be at all surprised if a list emerged but 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 and so should be avoided if possible. That said, it would be interesting to see a performance comparsion between innerHTML and DOM methods in IE6.