• Subscribe to this RSS Feed
  • window.location.href failing under MSIE 6
    11/02/2009 10:02PM

    So I had a function:

    function fv_loadUrl( parms )
    var elem = parms.elem;
    var href = parms.href;
    window.location.href = href;
    return true;

    Works like a champ in FireFox, but not in MSIE 6. I read a post that speculated the script was terminating before the page could load. Changing the return true; to return false; solved the problem.

  • Javascript Closures
    10/20/2009 6:11PM

    A technical article on Javascript Closures.

    And an article describing an approach to dealing with closure memory leaks.

    And an article describing a tool to track down memory leaks in MSIE.

  • A Firefox, Web Developer or FireBug bug
    10/19/2009 6:09PM

    This has represented a few hours of my life. At the present moment I don't know if the bug lies in firefox, the web developer extension or the firebug extension.

    I'm using Firefox 3.0.13 under Kubuntu Linux (9.04) with the Web Developer extension v.  1.1.8 and the FireBug extension v. 1.4.3.

    Consider the following small HTML page:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <title>FireFox a name ul bug</title>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

    <a name="comments"/>

    <ul id="comments_list">
                            <a href="void" >TEST</a>



    Using the http://validator.w3.org it validates.

    Opening the page in firefox and viewing the source yields the HTML above, as one would expect. What threw me for quote some time however is that if you do a "select all" on the page and right click -> view selection source you get:

    <html xmlns="http://www.w3.org/1999/xhtml"><head>
    <title>FireFox a name ul bug</title>
    <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    <a name="comments">
    </a><ul id="comments_list">
    <a name="comments">	</a><li>
    <a name="comments">		</a><div>
    <a name="comments">			</a><a href="void">TEST</a>


    As you can see there are now three erroneous <a name="comments"> interspersed between various tags. The same behavior happens under FireBug if you inspect the element.

    If you change the <a name="comments"/> to <a name="comments"></a> and repeat the select all view selection source experiment it yields:

    Which is correct. Since the page validates using the <a name="foo" /> notation, it seems to me it should not trash the DOM. 

    To see the bug in action, here's a test page.

    At the present moment, my formVista blogging software does not support anonymous comments. If you would like to comment on this article please register for an account using the register link in the upper left corner.

  • PHP split() is listed as deprecated and will be removed
    10/18/2009 3:51PM

    This is one of the liabilities of using a language long term that's in a high state of flux. As you continue to build larger and larger codebases, the work required to change that codebase as the language changes increases linearly.

    The formVista codebase started in 2001 and has been growing ever since. During that time the PHP language has changed significantly. In many of these cases these changes address fundamental design flaws in the language such as the whole way objects were done in PHP 4. (A change which will in the near future force me to evaluate each and every object assignment in the entire codebase. ouch.)

    So today I was looking at the PHP documentation for the split(). I'm endless forgetting if the string or the delimiter comes first. To my shock and horror split() is now deprecated.

    Of course you can use explode() or preg_split(), but it's another case of having to crawl through a codebase and change things. IMHO, in this case it's completely needless and arbitrary. If the underlying code that implements the split() function needs to be changed, then a wrapper function should be included so that legacy code does not break.

  • A Gotcha when using FireBug with Legacy HTML
    10/13/2009 5:55PM

    Firebug absolutely rocks. When tracking down the effects of errant CSS cascades, html quirks, DHTML side effects, etc, nothing beats Firebug. 

    However, today I ran into a little gotcha that consumed a few hours of my life. I wanted to align some drop downs and input fields nicely for the admin side of a new microblogging twitter/facebook/digg type component for formVista.

    The backend of formVista has a bunch of legacy code. Parts of it were written close to 10 years ago. Slowly as we develop out the new moderinzed FVML tag set, we're going through and updated the very dated looking backend components.

    I figured it was some style that was cascading down. Some margin, padding or alignment. Firebug showed nothing. I edited the styles inline. No joy. No matter what styles I applied the form fields displayed in the center of the form. I started to believe maybe I had run into a CSS bug in Firefox. 

    Then I realized the culprit. In formVista, components are hosted on pages but are completely separate. As a result, I don't spent alot of time actually looking at the HTML pages themselves. I focus on the component FVML files where all the work happens. The hosting HTML pages are just wrappers.

    Legacy wrappers.

    The page in question, where my newly styled component was living, used an ancient table based layout.

    <table width="100%">
    <td valign="top" align="center">

    And therein lies the problem. The align="center" was cascading down and overriding my styling. My guess is that firebug doesn't have a way to handle this case, or that I'm missing something in it's use.

    Re-arrange the hosting page to use a CSS layout and problem solved.