TW Blog :: Entries for Firefox and Co

Firefox Rises From The Ashes

Also relates to Web Standards

Well it was once called Pheonix, but that feels like a distant ancestor of the newly released Firefox Browser this week. I decided to hold back the excitement a few days to let the server load ease off, and finally tried out Firefox yesterday.

Already much acclaim has been accredited to this, version 0.8 of the pre-release browser of the future, and I can only add further praise. The development team have clearly put a lot of preparation into this latest release, even down to the finer details like the slick new icons and advertising logos.

The benefits for development have already been raised on Stylish Scripting, suffice to say I am eternally grateful to finally see the DOM Inspector integral to the outfit.

For general browsing, the extensions just get better and better. A favourite of mine has always been the RSS Reader Panel, being very lightweight and quick and easy to get running. This is better than ever with a check for updates option, OPML import and export, stripping of HTML tags in the tooltip summary and the ability to load the feed in the content window with custom CSS. The RSS icon has even been dusted off to blend naturally with the other icons.

To be expected from a Mozilla based browser, Firefox has excellent support for Web Standards, and the inclusion of the Windows executable installer should make setup more accessible to the average user. I could probably ramble on indefinately about the finer features, but all I will say is if you are reading this blog and have not tried Firefox yet, you don't know what you are missing!

Posted on Feb 12, 2004 at 21:28:03. [Comments for Firefox Rises From The Ashes- 0]

Key Press Event Handling

Also relates to Accessibility and DOM Scripting

On a current project, where accessibility is essential, I have integrated a stylesheet switcher on two pages where a mouseover affect on an image montage displays an introduction to each page in a separate box below the montage. The montage is structurally defined as a definition list, since it is a visual representation of links to pages on the site, with a brief description of each page. The stylesheet switcher allows users to switch the view to an actual list representation, if, for example, they are using only the keyboard. For CSS-enabled browsers without Javascript, the switcher loads a fresh page with the list display, and for non-display browsers the montage is just represented as a list from the outset.

While, I hope this will be effective under most conditions, I found a frustrating problem with supplementing the onclick event with an onkeypress event for keyboard users in Mozilla and co. When tabbing through the links on the page, as soon as the user tabs off the switcher (containing the event handler) the key press event is triggered. Well, of course, this is the correct behaviour, but Inte$net Exploder actually only triggers the event when the Return key is pressed, which is misleading to the developer, and incorrect interpretation.

The solution was to integrate a filter function that is called by the onkeypress event and this in turn only calls the style switcher function if the key pressed was Return

Here is the code:

function checkKeyPressed(evt, func, params)
{
  evt = (evt) ? evt : (window.event) ? event : null;
  if (evt)
  {
    var charCode = (evt.charCode) ? evt.charCode :
                   ((evt.keyCode) ? evt.keyCode :
                   ((evt.which) ? evt.which : 0));
    if (charCode == 13) func(params);
  }    
}

Where 13 is the ASCII value for the Return key. As well as passing the event as argument, I passed the function to be called and its parameters, to make the function generic. The scenario is just as relevant if using the event handlers to open a new window from a link (although this is strongly discouraged). The resulting anchor is as follows:

<a href="#" onclick="setStyleSheet('sheet'); return false;"
onkeypress="checkKeyPressed(event, setStyleSheet, 'sheet');"
>Switch to List View</a>

It is important that a false value is not returned in the key press event since this would prevent the user from tabbing beyond the style switcher link. The DHTML cookbook suggests the key detection in the filter should work in Netscape and Exploder back to v.4. It resolved the issue for this project.

Posted on Sep 14, 2003 at 16:44:31. [Comments for Key Press Event Handling- 7]