SitePoint Sponsor

User Tag List

Results 1 to 6 of 6
  1. #1
    SitePoint Member
    Join Date
    May 2005
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    conflicting javascript causing "ghost" of div to appear momentarily

    I'm trying to add Simon Willison's "panel switching" script:
    http://www.sitepoint.com/article/str...p-javascript/2
    to a site I'm developing:
    http://du.edu/intl/abroad/work/work2...argentina.html

    The three university links in the left column (Buenos Aires, Universidad del CEMA, and Universidad Nacional de Cuyo) trigger the
    Code:
    elem.style.display = 'block';
    in Simon's script that controls which div's content displays in the center column. I'm also calling in a few other scripts (some document.write to implement "unobtrusive javascript," and some other functionality such as a style switcher).

    The effect works well in IE6 on PC. There's a glitch in Firefox on PC ... If you take an action that calls a script in the "includes" js library, what looks like a copy of the "default" content div (the first, who's contents are initially visible onload) appears momentarily toward the top left of the page. This occurs when you mouse over the "Print this" and "Email this" links at bottom middle of the page or click the different size "T" to select alternate style sheets and choose a text size.

    Initially I thought it might be caused by multiple window.onload calls, as described by Bobby vanderSluis:
    http://www.bobbyvandersluis.com/arti...veshowhide.php.

    ...If you examine the examples above, you will notice that there is a brief moment where all toggleable elements are visible, before they get hidden.

    ... It is a public secret that the window.onload event lies at the core of this problem. It will only execute after the whole document, including all page assets like images and objects, is loaded. So if you work with a lot of content, a series of images or a slow server, you will always experience this negative side-effect.
    I added vanderSluis' code to distribute window.onload calls, but it didn't solve the problem.

    Part of the problem stems from the CSS that clips the show/hide divs, I think. But because the glitch occurs only when javascript activity is involved, I don't think it's the primary cause.

    Here's the CSS:
    Code:
    body#tier2_sa.programs div#centerColumn_indent	{
      height: 500px;
    }
    
    body#tier2_sa.programs div#centerColumn_indent div {
      overflow: auto;
      padding: 10px 20px 10px 10px;
      margin-top: 2em;
      width: 322px;
      height: 460px;
    }
    Here's Simon's "panels" code:

    Code:
    addEvent(window, 'load', et_init);
    
    var et_toggleElements = [];
    
    /* Initialisation */
    function et_init() {
         var i, link, id, target, first;
         first = true;
         for (i = 0; (link = document.links[i]); i++) {
             if (/\btoggle\b/.exec(link.className)) {
                 id = link.href.split('#')[1];
                 target = document.getElementById(id);
                 et_toggleElements[et_toggleElements.length] = target;
                 if (first) {
                     first = false;
                 } else {
                     target.style.display = 'none';
                 }
                 link.onclick = et_toggle;
             }
         }
    }
    
    function et_toggle(e) {
         /* Event handling code adapted from
            http://www.quirksmode.org/js/events_properties.html
         */
         if (typeof e == 'undefined') {
             var e = window.event;
         }
         var source;
         if (typeof e.target != 'undefined') {
             source = e.target;
         } else if (typeof e.srcElement != 'undefined') {
             source = e.srcElement;
         } else {
             return true;
         }
         /* For most browsers, targ would now be a link element; Safari
            however returns a text node so we need to check the node
            type to make sure */
         if (source.nodeType == 3) {
             source = source.parentNode;
         }
         var id = source.href.split('#')[1];
         var elem;
         for (var i = 0; (elem = et_toggleElements[i]); i++) {
             if (elem.id != id) {
                 elem.style.display = 'none';
             } else {
                 elem.style.display = 'block';
             }
         }
         return false;
    }
    
    /* Thanks to Scott Andrew */
    function addEvent(obj, evType, fn){
         if (obj.addEventListener) {
             obj.addEventListener(evType, fn, true);
             return true;
         } else if (obj.attachEvent) {
             var r = obj.attachEvent("on"+evType, fn);
             return r;
         } else {
    	    return false;
         }
    }
    Any suggestions would be appreciated.

    Eric Hobart

  2. #2
    SitePoint Guru
    Join Date
    Feb 2005
    Posts
    602
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    1) Scott Andrew's code has a bug. obj.addEventListener(evType, fn, true) should be obj.addEventListener(evType, fn, false)

    2) Instead of hiding the university divs on window.onload, use a stylesheet to hide all but the first. That circumvents the window.onload lag problem.

    3) The "ghost" div is a Firefox bug. It's been fixed in the latest internal build, but not in the latest public version. It's caused by setting the border in the hover selector in screen.css:

    Code:
    ul#emailPrint li a:hover	{
      border: 1px solid #fff;
      border-width: 1px 0 2px 0;
      text-decoration: none;
    }
    As far as I know, I don't think that border adjustment is necessary (in fact, it makes the link shift oddly a bit when you hover over it), so you should consider just removing it.

  3. #3
    SitePoint Member
    Join Date
    May 2005
    Posts
    3
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    "ghost" div still appearing when alternate style sheets activated

    Thanks Maian.

    I added the "false" to Andrews' script and took your advice and removed the border width properties from the Print and Email links ... I actuallly added those on purpose so the text and background image would "rise" on mouseover similar to the bottom toolbar items on the Mac interface. But, since they're the only links that behave that way on the site, your comment brought me to my senses.

    Removing the "border" and "border-width" eliminated the "ghost" div appearing when you moused over those links while using Firefox PC. The ghost div still appears when you activate one of the alternate style sheets using the "text size" links.

    I tied adding "display: none" to screen styles for all the toggleable divs by id per your suggestion:

    Code:
    body#tier2_sa.programs div#universityOne, body#tier2_sa.programs div#universityTwo, body#tier2_sa.programs div#universityThree  {
      display: none;
      overflow: auto;
      padding: 10px 20px 10px 10px;
      margin-top: 2em;
      width: 322px;
      height: 460px;
    }
    That didn't eliminate the "ghost" when the alternate style sheets links are used, but it did prevent all the divs from displaying when the page loads ... and I need the default div to display.

    I appreciate your help, and if you're still so inclined you can see the ongoing work at:

    http://du.edu/intl/abroad/work/scrol...argentina.html

    I changed the URL.

    I think the glitch is related to the additional information on the container divs introduced in this style:

    Code:
    body#tier2_sa.programs div#universityOne, body#tier2_sa.programs div#universityTwo, body#tier2_sa.programs div#universityThree  {
      overflow: auto;
      padding: 10px 20px 10px 10px;
      margin-top: 2em;
      width: 322px;
      height: 460px;
    }
    If the current relase of Firefox has trouble with the border declarations in the Print and Email <a> styles, maybe the overflow:auto and padding information in this is momentarily causing problems via the same bug.

    Anyway, thanks again for your prompt response. If I can't make this work with the mimic i-frame appearance, I'll remove those styles and use a more vanilla look. My intent was to offer users a visual clue that they weren't moving to a new page, rather that new content was appearing in the same page ... I didn't want them to be confused if they used the Back button. I thought the scroll illustrated that pretty well, but it may not be necessary.

    Thanks again,
    Eric

  4. #4
    SitePoint Guru
    Join Date
    Feb 2005
    Posts
    602
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Eric Hobart
    I tied adding "display: none" to screen styles for all the toggleable divs by id per your suggestion:

    Code:
    body#tier2_sa.programs div#universityOne, body#tier2_sa.programs div#universityTwo, body#tier2_sa.programs div#universityThree  {
      display: none;
      overflow: auto;
      padding: 10px 20px 10px 10px;
      margin-top: 2em;
      width: 322px;
      height: 460px;
    }
    That didn't eliminate the "ghost" when the alternate style sheets links are used, but it did prevent all the divs from displaying when the page loads ... and I need the default div to display.
    You also need to modify the script to set the first div's display to 'block':

    Code:
    function et_init() {
         var i, link, id, target, first;
         first = true;
         for (i = 0; (link = document.links[i]); i++) {
             if (/\btoggle\b/.exec(link.className)) {
                 id = link.href.split('#')[1];
                 target = document.getElementById(id);
                 et_toggleElements[et_toggleElements.length] = target;
                 if (first) {
                     first = false;
                     target.style.display = 'block';
                 } else {
                     //target.style.display = 'none';
                 }
                 link.onclick = et_toggle;
             }
         }
    }
    I think the glitch is related to the additional information on the container divs introduced in this style:

    Code:
    body#tier2_sa.programs div#universityOne, body#tier2_sa.programs div#universityTwo, body#tier2_sa.programs div#universityThree  {
      overflow: auto;
      padding: 10px 20px 10px 10px;
      margin-top: 2em;
      width: 322px;
      height: 460px;
    }
    If the current relase of Firefox has trouble with the border declarations in the Print and Email <a> styles, maybe the overflow:auto and padding information in this is momentarily causing problems via the same bug.
    Yeah, this is all triggered by overflow: auto. If you remove that, the email and print links can get back their border changes in their hover selector.

    I don't know all the ways to trigger this Firefox bug (actually Gecko bug - Gecko is the engine that powers Firefox), but I know that it involves redrawing the document while overflow is set to auto.

    I don't know of any workaround, but then again I usually don't use overflow: auto. Might want to search and ask around in the Firefox forums over at forums.mozillazine.org

  5. #5
    SitePoint Member Seinfeld's Avatar
    Join Date
    Jun 2004
    Location
    there's no place like 127.0.01
    Posts
    11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Lightbulb

    I had the exactly same problem using font-weight on a a:hover. After removing the font-weight, everything works smooth.
    I found more information about this wierdness on this thread.

  6. #6
    SitePoint Guru
    Join Date
    Feb 2005
    Posts
    602
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Found the bug entry in Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=238493

    Although it was fixed in Oct 05, the code had already branched into two versions several months before the fix - the stable one (1.7) and the experimental one (1.8). So the bug was fixed only for 1.8 and was deemed to unstable to port to 1.7 (i.e. it would need a lot of testing before going public). Firefox 1.0 is based off 1.7. Firefox 1.1 will be based off 1.8.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •