I’ve been incredibly busy lately, especially with work, but I finally have some time for personal stuff like posting again, yay. I’m currently stuck at the airport, and am leaving at 7AM this morning on vacation for 10 days on a tour of the west coast (Los Angeles, Disney World, Hollywood, Las Vegas, Grand Canyon, etc). The main reason for this get away is I’ll be meeting up with a good friend and his fiancée for their vacation and will be attending his wedding in Las Vegas ^_^.
I am currently on one of those open network connections at the airport that you have to pay to use, tunneled through one of my SSH servers, so I can bypassing their pay service and get online for free to post this :-). Hey, it’s their own fault for not securing it properly lol. I periodically kept getting dropped connections due to a weak signal, so I had to get back up after finding the connection and walk around, using my iPod to detect signal strengths until I found a better area with a stronger signal because. The thing is proving to be very useful ^_^. Anywho, on to the content of the post.
I’ve recently run into a number of new bugs [new to me at least] in both IE (version 7) and Firefox (version 3) that I have not encountered before and, as usual, have to program around to accomplish my tasks. I thought I’d discuss 3 of these bugs.
-
Relative (non absolute) base URL paths do not work in either Firefox or Internet Explorer.
Setting a base path for a website is often a necessity for websites that have web pages that are in subdirectories beyond the websites’s root directory. The reason for this is that the page-common layout of a web page usually refers to all images and content in a relative path. This is done for multiple reasons including:
- Ease of moving the site between addresses like for test stages, or if the site is served from multiple domain names.
- It’s easier to read source code URLs this way
- It makes the HTML files smaller; though this isn’t a problem for most users these days because internet connection speeds are much faster.
An example of W3C valid code that produces this error is as follows:
<head><base href="/MySite/">
The code, unfortunately, has to be an absolute URL like the following for current versions of IE and Firefox.
<head><base href="http://domain.com/MySite/">
One simple method to solve this problem is to use JavaScript to set an absolute base URL. Unfortunately, this then requires web browsers to have JavaScript enabled to work :-\. For this reason, this is really a quick fix for internal use that shouldn’t be put into production use unless JavaScript is required anyways.
The following code will set a base of “http://domain.com/MySite/” for “http://domain.com/MySite/Posts/Post1.html”.
<head>
<script type="text/javascript">
function GetBase() //Get the directory above the current path’s URL
{
return document.location.protocol+ //The protocol ("http:" or "https:")
'//'+ //End the protocol section with a //
document.location.hostname+ //The host (domain)
document.location.pathname.replace(/(\/[^/]*){2}$/,'')+ //This moves up 1 directory from the current path. To move up more directories, set the "2" in this line to NumberOfDirectoriesToMoveUp+1
'/'; //Add a '/' to set the end of the path as a directory
}
document.write('<base href="'+GetBase()+'">'); //Write a BASE object to set the current web page’s base URL to GetBase()
</script>
</head>
A simpler solution is to just have your parsing language (PHP for example) detect the server you are running on and set the proper base URL accordingly. This method assumes you know all the possible places/addresses your website will run on.
<head><base href="<?=($_SERVER['HTTP_HOST']=='domain.com' ? 'http://domain.com/MySite/' : 'http://domain2.com/')?>"></head>
-
Reserved keywords in IE cannot be used as object members
Example (JavaScript):
var MyObject={};
MyObject.return=function() { return true; }
Solution: Instances of this must be encoded in strings
var MyObject={};
MyObject['return']=function() { return true; }
This also occurs for other reserved keywords like “debugger” and “for”.
-
IE’s window does not have the “hasOwnProperty” member function like ALL OTHER OBJECTS
This is a major nuisance because trying to find out if a variable exists and is not a prototype in the global scope is an important function. *sighs*
The fix for this is using “window.VARIABLE!==undefined”, though this won’t tell you if the variable is actually instanced or [again] if it is part of the prototype; only if it is defined.
One more JavaScript engine difference between IE and Firefox is that in IE you can’t end a hash with an empty member. For example, the following works in Firefox, but not IE:
var b={a:1, b:2, c:3, d:4, };
This shouldn’t really be done anyways, so it’s not really a problem IMO. I ran across this when converting some bad Perl code (generated by YACC) which coincidentally allows this.
It’s really hard making everything compatible across all web browser platforms when they all contain so many nuances and bugs :-\.
