Technology Tales

Worth the attention?

The latest edition of Web Designer has features and tutorials on modern trends, including new ways to use fonts and typography in websites. One thing that's at the heart of the attention is the @font-face CSS selector. It's what allows you to break away from the limitations of whatever fonts your visitors might have on their PC's to use something available remotely.

In principle, that sounds like a great idea, yet there are caveats. The first of these is the support for the @font-face selector in the first place, though modern browsers I have tested handle this reasonably well. These include the latest versions of Firefox, Internet Explorer, Opera and Chrome. While the new fonts may render OK, there's a short delay in the full loading of a web page. With Firefox, the rendering seems to treat the process like an interleaved image, so you may see fonts from your own PC before the remote ones come into place, a not too ideal situation in my opinion. Also, I have found that this is more noticeable on the Linux variant of the browser than its Windows counterpart. Loading a page that is predominantly text is another scenario where you'll see the behaviour more clearly. Having a sizeable image file loading seems to make things less noticeable. Otherwise, you may see a short delay to the loading of a web page because the fonts have to be downloaded first. Opera is a particular offender here, with IE8 loading things rather quickly and Chrome not being too bad either.

In the main, I have been using Google's Fonts Directory but, in the interests of supposedly getting a better response, I tried using font files stored on a test web server only to discover that there was more of a lag with the fonts on the web server. While I do not know what Google has done with their set-up, using their font delivery service appears to deliver better performance in my testing, so it'll be my choice for now. Though there's Typekit too, I'll be hanging onto to my money in the light of my recent experiences.

After my brush with remote font loading, I am inclined to wonder if the current hype about fonts applied using the @font-face directive is deserved until browsers get better and faster at loading them. As things stand, they may be better than before, while the jury's still out for me, with Firefox's rendering being a particular irritant. Of course, things can get better...

Consolidation

For a while, the Windows computing side of my life has been spread across far too many versions of the pervasive operating systems with the list including 2000 (desktop and server), XP, 2003 Server, Vista and 7; 9x hasn't been part of my life for what feels like an age. At home, XP has been the mainstay for my Windows computing needs, with Vista Home Premium loaded on my Toshiba laptop. The latter variant came in for more use during that period of home computing "homelessness" and, despite a cacophony of complaints from some, it seemed to work well enough. Since the start of the year, 7 has also been in my sights with beta and release candidate instances in virtual machines, leaving me impressed enough to go popping the final version onto both the laptop and in a VM on my main PC. Microsoft finally has got around to checking product keys over the net, so that meant a licence purchase for each installation using the same downloaded 32-bit ISO image. 7 is still doing well for me, so I am beginning to wonder whether having an XP VM is becoming pointless. The reason for that train of thought is that 7 is becoming the only version that I really need for anything that takes me into the world of Windows.

Work is a different matter, with a recent move away from Windows 2000 to Vista heavily reducing my exposure to the venerable old stager (businesses usually take longer to migrate, and any good IT manager usually delays any migration by a year anyway). 2000 is sufficiently outmoded by now that even my brother was considering a move to 7 for his work because of all the Office 2007 files that have been coming his way. While he may be no technical user, the bad press gained by Vista hasn't passed him by, so a certain wariness is understandable. Saying that, my experiences with Vista haven't been unpleasant, and it always worked well on the laptop, while the same also can be said for its corporate desktop counterpart. Much of the noise centred around issues of hardware and software compatibility, and that certainly is apparent at work with my having some creases left to straighten.

With all of this general forward heaving, you might think that IE6 would be shuffling its mortal coil by now, but a recent check on visitor statistics for this website places it at about 13% share, tantalisingly close to oblivion but still too large to ignore it completely. All in all, it is lingering like that earlier blight of web design, Netscape 4.x. If I was planning a big change to the site design, setting up a Win2K VM would be in order, not to completely put off those labouring with the old curmudgeon. For smaller changes, the temptation is not to bother checking, but that is questionable when XP is set to live on for a while yet. That came with IE6 and there must be users labouring with the old curmudgeon, and that's ironic with IE8 being available for SP2 since its original launch a while back. Where all this is leading me is towards the idea of waiting for IE6 share to decrease further before tackling any major site changes. After all, I can wait with the general downward trend in market share; there has to be a point when its awkwardness makes it no longer viable to support the thing. That would be a happy day.

Ridding the Google Toolbar dictionary of erroneously added words

Butterfingeredness can happen to anyone, and it's always nice to know to remove words added to custom dictionaries in error. Many of my blog postings have had their spellings checked using a button on the Google Toolbar, so I have a vested interest in knowing how to remove any bloomers. Thankfully, they have a useful page telling you exactly what you need to do for Firefox and Internet Explorer. As is often said, you can never be too careful...

Suffering from neglect?

There have been several recorded instances of Google acquiring something and then not developing it to its full potential. FeedBurner is yet another acquisition where this sort of thing has been suspected. Changeovers by monolithic edict and lack of responsiveness from support forums are the sorts of things that breed resentment in some that share opinions on the web. Within the last month, I found that my FeedBurner feeds were not being updated as they should have been, and it would not accept a new blog feed when I tried adding it. The result of both these was that I deactivated the FeedBurner FeedSmith plugin to take FeedBurner out of the way for my feed subscribers; those regulars on my hillwalking blog were greeted by a splurge of activity following something of a hiatus. There are alternatives such as RapidFeed and Pheedo, but I will stay away from the likes of these for a little while and take advantage of the newly added FeedStats plugin to keep tabs on how many come to see the feeds. The downside to this is that IE6 users will see the pure XML rather than a version with a more friendly formatting.

position: static?

CSS positioning seems to be becoming a nightmare when it comes to IE6 support. While I am aware that the likes of 37signals have stopped making their products work with it, there remain plenty of people who stick or are stuck with the old retainer. I am one of the latter because of the continued use of Windows 2000 at my place of work, though a Windows Vista roll-out has been mooted for a while now. If nothing else, it keeps me in the loop for any inconsistencies that afflict the display of my websites. Positioning of an element within the browser window rather than within its parent element is one of these, and it looks as if specifying a position of relative in a stylesheet is part of this. Apparently, it could be down to its non-triggering of IE's haslayout property. Though it might be a hack, I have found that static positioning has helped. While I'll continue to keep my eye out for a better solution if it exists, the static option seems to have no detrimental effect in IE7, IE8, Firefox, Safari, Chrome or Opera.

A radical new look on the way for WordPress' administration area

One thing that you can never say about Automattic is that it stands still for very long. That may generate adverse commentary from some, yet it's bad to leave things stagnate, too. In fact, resting on laurels also generates flak, so you can't please everyone all the time.

Earlier on this year, the WordPress administration screens went through something of an overall for version 2.5. In hindsight, it wasn't terribly dramatic, but the prospect had me checking out what was happening with the development version and contributing to the project in my own small way. Now, it appears that a bigger upheaval is in prospect with wireframes and what not being brought into play on the design side.

The first change that anyone will notice is that the navigation has moved from the top to the side, and that some things have been moved around and renamed. Another thing that you'll see soon enough is that there is a QuickPress section added to the dashboard screen for those quick and short postings. Sticking with the subject of content creation, alterations to post and page editing screens and the link creation screen are obvious too. The thing that really comes to mind here is the level of customisation on offer, so you can make yourself feel right at home: some of the screen furniture can be moved about, and you can remove what you feel is nothing but useless clutter. Content generates comments, so the addition of keyboard shortcuts for comment moderation should be a boon for those with very active readers.

Some functionality currently added by plugins is getting incorporated in the main application. An example is automatic upgrades of WordPress itself. In the development version, it installs the latest nightly build, but I am certain that it can be made to point to the latest stable release. That makes it more convenient for keeping a backseat eye on things rather than getting stuck into the hurly-burly of checking on what's in Subversion.

There are some pieces that remain incompletely functional at present, such as the Inbox and Media added to this post pieces, but I have seen nothing that used to work to be broken. So, while the development version of WordPress is more of a work in progress than I have seen for a while, it will do what you need it to do. Since you always need to be cautious, I'd advise you to keep away until it's ready for the big time, unless you have the knowledge to put things back should the undesirable befall your blog. I had an automatic WordPress update kick in maintenance mode without turning it off again. Nothing happened to the database, so a manual re-installation was all that was required to restore order. Otherwise, the development installation remains relatively stable, though there are display problems in IE6 that do not afflict either Firefox, Opera or even IE8 Beta2.

All in all, these changes will make the next major WordPress release a substantial one, and I have little doubt that the new administration interface will make for many comments. While I must admit that I wasn't too taken with it when I first glimpsed it in the crazyhorse branch, it now seems to be growing on me. The most significant change on the aesthetic front is that there's a lot less whitespace, about which may or may not float your boat. In any event, you can always change the colours like I have to make things more amenable.

Even so, I reckon that WordPress 2.7 will be a major step forward when it comes, one that I might like. Saying that, I reckon that the release date is a good while away for now, and the fact that 2.6.2 is being readied for release is telling in itself. Leaving plenty of time to remove any roughness is never a bad thing, especially so when you see the changes that are being made. Meanwhile, I am certain that most people can wait.

Running Internet Explorer on Linux

On first sight, this probably sounds daft given how good Firefox is, yet you cannot ignore those surfing the web using the ever pervasive Internet Explorer when doing some web development. Though using virtualisation is a solution to the need, it can mean that you need to set up a web server with Perl, PHP, MySQL and the like in a virtual machine, all for a little offline testing and then there's the potential for a lot of file copying too. Otherwise, you are trying to sneak things online and catch the glitches before anyone else does, never a good plan.

Therefore, having the ability to run IE to test your offline LAMP set up is a boon, and IES4Linux allows you to do what's really needed. Naturally, WINE is involved, so some flakiness may be experienced, even after the ever useful API library's reaching version 1. Otherwise, all usually runs well once you work your way through the very helpful instructions on the IES4Linux website. I did get a misplaced message about the version of WINE that I was using, and Python errors made a worrying appearance, but neither compromised the end result: a working IE6 installation on my main Ubuntu box.

IE5 and IE5.5 are also on offer if you're interested but, after looking at my visitor statistics, I think that I can discount these. IE7 and the work-in-progress IE8 make no appearance on the availability list. The absence of IE7 is not a big problem as it might appear because coding for IE6 sufficiently suffices for IE7, even now; IE8 may not be the same in this regard, but we shall see. Even so, a later browser release does mean a more secure version, and I reckon that including IE7 should be next on the project's to-do list. Saying that, what we have now is far better than nothing at all.

LVHA…

On my web design journey, I have learned the wisdom that CSS styles for hyperlinks should be defined like the following:

a:link {...}

a:visited {...}

a:hover {...}

a:active {...}

List out the names of the pseudoselectors, and you'll soon work out where they got LVHA: Link, Visited, Hover and Active. However, I have recently spotted the following being used:

a {...}

a:hover {...}

The trick here is to define your style globally and only define specifics for the relevant pseudoselector, hover in this example. It works well in the likes of Mozilla and Opera, but Internet Explorer is another story. Even IE7 needs the LVHA treatment. I spotted this when I observed unexpected changes in the appearance of link text after visiting the link: visited links starts to change colour. While I know that the likes of Jakob Nielsen frown upon non-changing link colour, I choose to ignore this and keep it constant, so following the LVHA approach is needed to keep things as I would like them.

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.