Yet Another Software Blog

I don’t like to add special effects when a link is being hovered, as I think that the reader should be able to identify links without moving the mouse, and when the courser is over a link it should be enough that the cursor changes from an “arrow” to a “hand”.  Some people think otherwise and most of them like to add some kind of border around the link when it is being hovered.

The problem with adding a border around a link is that it expends the area the browser reserves for the link and cause a redraw of the content. Most of the times when the link is a textual link there is no ill effect, but when the link is actually an image the content around it will “jump” to accommodate the new size of the link (image + border).

The best way to avoid the “jump” is to preallocate an empty space around the image which will be used to display the border.

For example if our current CSS rules are

a:hover  {text-decoration:none;}
.entry a:hover {border-bottom:1px dotted; }

Should be changed to

a:hover  {text-decoration:none;}
 .entry a:hover {border-bottom:1px dotted; padding-bottom:0;}
 .entry a {padding-bottom:1px;}

No disrespect to the efforts of the developers, and the solid reasoning of the judges, but in my humble opinion the winner of the 2009 wordpress plugin competition – the section widget which

provides a way to display section specific content on your WordPress sidebar with an easy to use interface. This new version comes with tabs support, so creating your tabbed section widget is just a few clicks away.

is not good enough to receive the prize.

I only needed to look at the screen shots to decide that I’m not going to recommend this plugin to any one

Who are going to be the users of this plugin? This screenshot alone displays more hardcore wordpress buzzwords than the “all I want is a simple blog” crowd understands, while it might be easier for the WP focused developers to simply add new sidebar for the places where the normal one is not good enough.

Oh, it even worse than that. When I want to hide a widget from the sidebar at a specific page, I just use CSS. It might not be the ideal solution as it wastes some bandwidth and CPU cycles, but your time is probably much more expensive than the cost of bandwidth and CPU.

In my opinion this type of contest should be decided on mainly two factors:

• Does it solve a real life problem for many WP users
• Can a non geek teenager use the plugin successfully without help

Based on this criteria, my favorites were

• Advanced Export for WP and WPMU which solves the problem of exporting big blogs from shared hosting were you don’t have a direct access to the DB. I only wish there was also a simple way to automate the process.
• One time password. In a world were we blog from a coffee shop via unsecured WiFi it is actually a security madness to use our password (which we probably use at other sites as well). A one time password is probably the best solution after installing an SSL for the blog. I wish it could have been integrated with the FTP server.

Why my site is “rocking” when it is being loaded? seems to be a question not being asked enough. Even in digg.com, the capital of nerddom, the site rocks after it content was loaded to show an infomercial at the top of the page.

It is annoying because you actually start reading, or at least scan the page, when the text start to show. When the page “rocks” it disorients you, and you have to search for the location of the text you were reading.

It used to be caused by images embedded in the HTML code. When the browser reads gets to an IMG tag when parsing the HTML, it has no way to know what are its height and width, until after the image was fetched from the server, and therefor how much visual space it should reserve for it.
This impacts the browsers decision where to place the other items of the page, and when finally the image is loaded the browser finds its height and width and has to recalculate the position of the other elements on the page (a process also known as reflow).

The cure for this is very simple – in most cases you know in advance what is the expected dimension of the image when it is an integral part of the design, or you can use some library to calculate if it is stored on your server, therefor you can set the width&height attributes of the IMG element or specify it in a CSS style rules. This leaves as a problematic issue only the situations in which you embed an image which is located on other server not controlled by you, but this probably happens very rarely for most of the sites.

AJAX scripts are another cause for “rocking” . The main reason for AJAX “rocking” is post loading of dynamic information, usually done when the site serves static HTML pages, probably because of performance related reasons, but needs to show some dynamic content, and therefor loads it after the page was loaded.

As with the images, you simply have to specify the height and width in advance – since the target area for the data received from the AJAX operation is usually a DIV, just specify its height and width.

Note: There is a fundamental difference between rocking when the page loads as result of AJAX, and “rocking” when page changes as result of AJAX. When the page “rocks” after a user initiated an action, the user is idle while waiting for the page to change, and therefor the “rocking” is not as annoying (especially if you conceder that the alternative is full page load).