Tag: javascript

Custom JavaScript error notification

Debugging JavaScript errors is a time-consuming effort requiring keen eyes and a sharp mind.

MSIE typically only gives a cryptic ‘Object Expected’ error message and little more (even with the Microsoft Script Debugger installed!).

Some tools like FireBug and the Venkman debugger (both for Mozilla/Firefox) help in this matter, but often it helps to have an alert when an issue occurs.

Here’s a simple implementation that I’ve found useful…

[script type=”text/javascript”]
window.onerror=myErrorHandler;

function myErrorHandler(msg,url,l){
var txt=”There was an error on this page.\n”;
txt+=”Error: ” + msg + “\n”;
txt+=”URL: ” + url + “\n”;
txt+=”Line: ” + l + “\n\n”;
txt+=”Click OK to continue.\n\n”;
alert(txt); return true; }
[/script]

REFERENCES:

That’s it….

MSIE6 background-image caching (or lack of it…) and flickering

This has been an annoyance of this (IMHO very buggy) browser since it was first beta tested. Earlier (5.x) and newer (7.x) versions do not exhibit this problem.
For some reason Microsoft developers broke the caching mechanism for background images, particularly when defined in CSS. This makes for slow screen painting as well as wasted network traffic as each occurrence of the image becomes a new HTTP request to the webserver. This also causes a notable delay in those images painting on the screen and ‘flicker’ when the images are used in CSS rollover effects. Since the image obviously isn’t changed it results in many ‘HTTP 304 Not Modified‘ entries in the server logs.

Fixes…

1. You CAN/SHOULD set the Expiry for the images, however this can be problematic. Since I typically run Apache HTTPD, those instructions follow:

a) Set an explicit expiry time based on MIME types in the http.conf file.

[instructions in separate post]

b) Enable .htaccess for the server and allow its usage in individual folders on the server.

[instructions in separate post]

c) Use client-side technologies to hack around the problem…. you can use many CSS tricks, but I’ve found that JavaScript is the easiest (most compatible) method.

Add the following to a method executed in the onload event of the page…

<script type=”text/javascript”>
try {
document.execCommand(‘BackgroundImageCache’, false, true);
} catch(e) {}
</script>
NOTE: MSIE will execute the Javascript, Mozilla and other browsers will throw an exception and wind up in the catch block… which ignores the problem.

UPDATE:
With the use of conditional comments, this can be added to an MSIE specific JS file, or even better an MSIE specific CSS file containing the following:


html {
filter: expression(document.execCommand("BackgroundImageCache", false, true));
}

REFERENCES:

Auto focus ‘first visible’ form field on page…

Occassionally there comes a need to set the focus within a web page to the first ‘visible’ form field, here’s the most convenient I’ve found thus far…

Implementation:
1. Add the following Javascript to the HEAD section of your page.

function formfocus() {
if(document.forms.length > 0)
{
var formElements = ["text", "checkbox", "radio", "select-one", "select-multiple", "textarea"];
var form = document.forms[document.forms.length-1];
for (var j = 0; j < form.elements.length; j++)
{
var field = form.elements[j];
for(var x = 0; x < formElements.length; x++)
{
if (field.getAttribute("type") == formElements[x])
{
field.focus();
return false;
}
}
}
}
}

2. Add the function call to the BODY tag…

<body onload="formfocus();">

That’s it! Enjoy!

JavaScript (intro)

JavaScript is one of the foundations of the internet as we currently know it, but is often misunderstood. It is the “J” in AJAX (to be discussed elsewhere), and is typically used for creation of interactive browser applications with client-side (browser) functionalities such as FORM validation and manipulation of onscreen elements via the DOM (to be discussed elsewhere).

JavaScript is more appropriately called ECMAScript, as it is a ‘Standard’ from the ECMA organization. Early incarnations of this specification were called LiveScript (by Netscape). Microsoft, in typical form, created a VisualBASIC like version that they called JScript, though while mostly compatible, has some proprietary differences.

Implementation:
It’s always preferred to add this to your HEAD section (or the equivalent in HTTP Headers):

<meta http-equiv=”Content-Script-Type” content=”text/javascript” />

To include external files containing JavaScript:

<script type=”text/javascript” src=”/filename.js”></script>

To include XHTML compliant blocks of JavaScript in your page:

<script type=”text/javascript”>
<!– <![CDATA[
…
//]]> — >
</script>

DO NOT use the deprecated ‘language’ attribute:

<script language=”JavaScript”>
…
</script>

<option disabled=”disabled”>?</option> not implemented in MSIE

This was a complete shock to me recently, even after years of ‘assuming’ that something this simple would be well supported… after all, this is pretty basic.

All modern browsers Mozilla (Firefox), Safari, Opera, even old Netscape (eg: 4.x) browsers work properly with the following code and comply with the W3C HTML specification making the value “Two” unable to be selected by the user within the browser… MSIE doesn’t comply and allows the user to select it!

<form name="example" action="#" method="get">
<select name="test">
<option value="1">One</option>
<option value="2" disabled="disabled">Two</option>
<option value="3" selected="selected">Three</option>
<option value="4" style="color:green;">Four</option>
</select>
</form>

This ‘failure’ to support standards actually seems to be due to the way the <select> tag is handled by the browser… it passes off control to the operating system (Windows). Obviously, Microsoft was able to pass along ‘other’ attributes, like ‘style’ in the example above, but chose to not support ‘disabled’.

In this case, the developer is left to find a solution… easiest is to just remove the unwanted value from the list of options, otherwise it requires extensive amounts of JavaScript.

Good luck!

NOTE: Tested on MSIE 6.0 (WinXP), hopefully Microsoft will fix this in MSIE7.

… vs. …

The href=”#” markup is pretty common in many HTML primers and most developers are used to seeing it, and don’t even question why it might be ‘bad’. Here’s the problem… “#” is supposed to be used for anchors within a page (for times when you want a user to be ‘scrolled’ to certain content on the (sometimes very long) page. Typically this is done to link from an index to specific paragraphs or chapters.

Example:


Title
<a name="top"></a>
<a href="#chap1">Chapter 1</a>
<a href="#chap2">Chapter 2</a>
<a href="#chap3">Chapter 3</a>

<a name="chap1"></a>Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Quisque aliquet commodo diam. Ut scelerisque, nisl id laoreet consequat, pede lacus consequat est, id consectetuer neque augue a odio.
<a href="#top">Back to Top</a>
<a name="chap2"></a>Cras vel odio. Vestibulum fermentum rhoncus sapien. Donec vehicula euismod nunc. Duis malesuada erat non nulla. Cras ullamcorper diam ut ante. Nullam quam felis, suscipit vel, ultrices non, laoreet sit amet, nulla.
<a href="#top">Back to Top</a>
<a name="chap3"></a>Cras et sem vel enim hendrerit accumsan. Fusce lobortis lobortis quam. Proin egestas justo a purus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos.
<a href="#top">Back to Top</a>

The problem… and the cure…
If you use href="#" by itself, the browsers behavior is to take you to the very top of the page (like when it first loads). This is great on static sites, but as soon as you start adding some JavaScript events (onclick being most common), you’ll start seeing the problem.

Most developers, when coding the ‘onclick’ for an href, automatically (or by habit, or reliance on “tools”), stick the href=”#”…. by doing so, their action occurs, but as an unwanted side-effect, the browser also scrolls the content. This often takes an incredible amount of time for them to realize what’s really happened, particularly because you need enough content on the page to even see the scroll occur.

The solution, just replace the href=”#” to have a null javascript event… for compatibility with a wide variety of browsers, I recommend using href=”javascript:void(0);” in theses cases.

Good Luck!

Whoami

I’m skotfred, aka ‘Giant Geek’, developer of (predominantly web-based) applications. Primary development done with JSP/Java, PHP, XHTML/CSS/JavaScript. Previous applications in VisualBASIC, C/C++, Perl, COBOL/CICS, BASIC (various), Assember (PC & MVS), and Pascal.

Standards ARE everything, particularly when building for multiple platforms… look for more ramblings soon!