Re: JS Stops working in IE6

Discussion in 'HTML' started by VK, May 17, 2008.

  1. VK

    VK Guest

    On May 18, 12:03 am, sheldonlg <sheldonlg> wrote:
    > Gregor Kofler wrote:
    > >> sheldonlg meinte:
    > >>> sheldonlg wrote:
    > >>>> Here is an app: www.sheldonlg.com/JSstops.htm

    >
    > >>> I have the entire menuing removed, tags and css stuff, in
    > >>>www.sheldonlg.com/JSstops2.htm.

    >
    > >>> This expands three levels, but not the fourth. Removing things
    > >>> causes all four levels to appear.

    >
    > >> Well I suppose it doesn't work in *any* browser. And "refreshView is
    > >> not defined". Apart from that: nuttin' to click.

    >
    > In order to clear up confusion, the new app is atwww.sheldonlg.com/JSstop1.com
    >
    > That one has no buttons or dropdown list. All it gas that is clickable
    > is the plus sign to expand the nested tables. With this app, it stops
    > after one expansion in IE6, but expands all three times in FF.


    There is not JSstop1.html on your server. I see
    http://www.sheldonlg.com/JSstops.htm
    http://www.sheldonlg.com/JSstops2.htm
    there and both seem working as intended with IE6
     
    VK, May 17, 2008
    #1
    1. Advertising

  2. VK

    VK Guest

    On May 18, 12:40 am, sheldonlg <sheldonlg> wrote:
    > I also just test the JSstops1.htm on IE7. It expands two levels but not
    > the third. FF expands them all.


    OK, I think I know the problem. The table default display style
    differs by browsers: "block", "table-block" and crazy mess. This is
    why one _never_ _ever_ does two things with tables:

    1) you do not override default display style.
    2) you do not set it to any explicit values. Instead you set it to
    "" (empty string) if needed to reset to default.

    So in your code all initially visible tables must have no display rule
    at all: carefully check CSS and scripting.

    All initially hidden tables have display:none

    To show a table you set display to empty string:
    tableReference.style.display = '';

    To hide it again you set to none:
    tableReference.style.display = 'none';
     
    VK, May 17, 2008
    #2
    1. Advertising

  3. VK

    VK Guest

    On May 18, 1:33 am, sheldonlg <sheldonlg> wrote:
    > VK wrote:
    > > On May 18, 12:40 am, sheldonlg <sheldonlg> wrote:
    > >> I also just test the JSstops1.htm on IE7. It expands two levels but not
    > >> the third. FF expands them all.

    >
    > > OK, I think I know the problem. The table default display style
    > > differs by browsers: "block", "table-block" and crazy mess. This is
    > > why one _never_ _ever_ does two things with tables:

    >
    > > 1) you do not override default display style.
    > > 2) you do not set it to any explicit values. Instead you set it to
    > > "" (empty string) if needed to reset to default.

    >
    > > So in your code all initially visible tables must have no display rule
    > > at all: carefully check CSS and scripting.

    >
    > > All initially hidden tables have display:none

    >
    > > To show a table you set display to empty string:
    > > tableReference.style.display = '';

    >
    > > To hide it again you set to none:
    > > tableReference.style.display = 'none';

    >
    > I made that change and it didn't change anything.


    I really need to go now, sorry. I will take another look today evening.
     
    VK, May 17, 2008
    #3
  4. VK

    VK Guest

    On May 18, 1:54 am, sheldonlg <sheldonlg> wrote:
    > VK wrote:
    > > On May 18, 1:33 am, sheldonlg <sheldonlg> wrote:
    > >> VK wrote:
    > >>> On May 18, 12:40 am, sheldonlg <sheldonlg> wrote:
    > >>>> I also just test the JSstops1.htm on IE7. It expands two levels but not
    > >>>> the third. FF expands them all.
    > >>> OK, I think I know the problem. The table default display style
    > >>> differs by browsers: "block", "table-block" and crazy mess. This is
    > >>> why one _never_ _ever_ does two things with tables:
    > >>> 1) you do not override default display style.
    > >>> 2) you do not set it to any explicit values. Instead you set it to
    > >>> "" (empty string) if needed to reset to default.
    > >>> So in your code all initially visible tables must have no display rule
    > >>> at all: carefully check CSS and scripting.
    > >>> All initially hidden tables have display:none
    > >>> To show a table you set display to empty string:
    > >>> tableReference.style.display = '';
    > >>> To hide it again you set to none:
    > >>> tableReference.style.display = 'none';
    > >> I made that change and it didn't change anything.

    >
    > > I really need to go now, sorry. I will take another look today evening.


    Seems like some broken table glitch on IE6. As you may notice the
    third table is blocked for user interaction, see the cursor style or
    try to set a simple alert on image click.
    If we replace

    <td colspan="15">
    <table id="contract_900135_01-Jan-2008_both_all" ...

    to

    <td>
    <table id="contract_900135_01-Jan-2008_both_all" ...

    then the things are coming back to life right away.
    Are you sure that there are indeed exactly 15 cells to span?
     
    VK, May 18, 2008
    #4
  5. sheldonlg wrote:
    > One additional piece of information. I changed the header to
    >
    > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    > "http://www.w3.org/TR/html4/loose.dtd">
    > <html>
    > <head>
    > <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    >
    > (www.sheldonlg.com/JSstops7.htm)
    >
    > and it still exhibits the broken behavior of not expanding past the
    > first nested table. So, it isn't the "XHTML", nor the "strict". Also,
    > it isn't "quirks mode" since this is now straight html4.


    No that's a transitional doctype, strict is:

    <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">


    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, May 18, 2008
    #5
  6. VK

    VK Guest

    > > Are you sure that there are indeed exactly 15 cells to span?
    >
    > No, there aren't. I have always used a large number when I wanted to
    > span all columns of a table and it has always worked in the past.


    That's a nasty way of doing things, really. But whatever.

    > As you may have noticed, what I am trying to do with this sample app is
    > not to "get the sample app to work". Rather, I am trying to get at the
    > root cause of the problem so that I can get my real app to work. That
    > is why I have left the sample app at the minimum I can get to and still
    > have it exhibit the broken behavior.


    No, it is not a minimum case: there is still plenty of extra stuff
    floating around. For example do not use the current CSS file, just
    load the page w/o styling: and the problem goes away. So either
    something sneaky in your CSS rules, or some particular CSS rule acting
    strange for IE6 with malformed tables. Keep cleaning up. For the
    starter make a page loading an empty CSS file and then start adding
    ruleset by ruleset from the current CSS checking the behavior after
    each modification.
     
    VK, May 18, 2008
    #6
  7. Jonathan N. Little wrote:
    > sheldonlg wrote:
    >> One additional piece of information. I changed the header to


    This is _not_ the header.

    >> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    >> "http://www.w3.org/TR/html4/loose.dtd">
    >> <html>
    >> <head>
    >> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    >>
    >> (www.sheldonlg.com/JSstops7.htm)
    >>
    >> and it still exhibits the broken behavior of not expanding past the
    >> first nested table. So, it isn't the "XHTML", nor the "strict". Also,
    >> it isn't "quirks mode" since this is now straight html4.

    >
    > No


    Yes, it is not XHTML, and it is not HTML 4.01 Strict. Yes, it is HTML 4.

    > that's a transitional doctype, strict is:


    http://hsivonen.iki.fi/wannabe/

    > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    > "http://www.w3.org/TR/html4/strict.dtd">


    However, HTML 4.01 Strict is not required for a UA to use Standards
    Compliance Mode instead of Quirks/Compatibility Mode; including the
    system identifier suffices.

    See http://quirksmode.org/


    F'up2 alt.html

    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, May 18, 2008
    #7
  8. In alt.html, Jonathan N. Little wrote:

    > sheldonlg wrote:
    >> One additional piece of information. I changed the header to
    >>
    >> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    >> "http://www.w3.org/TR/html4/loose.dtd">
    >> <html>
    >> <head>
    >> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    >>
    >> (www.sheldonlg.com/JSstops7.htm)
    >>
    >> and it still exhibits the broken behavior of not expanding past the
    >> first nested table. So, it isn't the "XHTML", nor the "strict".
    >> Also, it isn't "quirks mode" since this is now straight html4.

    >
    > No that's a transitional doctype, strict is:
    >
    > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    > "http://www.w3.org/TR/html4/strict.dtd">


    ...and he still needs to remove all those extra " />" so it validates.

    .... title="Contemporary" type="text/css" />
    .... <br />
    and others.

    The W3 CSS validator chokes; won't display errors.
    "Servlet has thrown exception:javax.servlet.ServletException: Timed
    out"

    The WDG CSS validator reports dozens of errors.
    http://www.htmlhelp.com/tools/csscheck/
    and enter URL
    http://www.sheldonlg.com/css/style1.css
    Uncheck "Include warnings" to see errors only.

    --
    -bts
    -Friends don't let friends drive Windows
     
    Beauregard T. Shagnasty, May 18, 2008
    #8
  9. Thomas 'PointedEars' Lahn wrote:
    > Jonathan N. Little wrote:
    >> sheldonlg wrote:
    >>> One additional piece of information. I changed the header to

    >
    > This is _not_ the header.
    >
    >>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    >>> "http://www.w3.org/TR/html4/loose.dtd">
    >>> <html>
    >>> <head>
    >>> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    >>>
    >>> (www.sheldonlg.com/JSstops7.htm)
    >>>
    >>> and it still exhibits the broken behavior of not expanding past the
    >>> first nested table. So, it isn't the "XHTML", nor the "strict". Also,
    >>> it isn't "quirks mode" since this is now straight html4.

    >> No

    >
    > Yes, it is not XHTML, and it is not HTML 4.01 Strict. Yes, it is HTML 4.
    >
    >> that's a transitional doctype, strict is:

    >
    > http://hsivonen.iki.fi/wannabe/


    Excuse me, and this is applicable th whom?

    >
    >> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    >> "http://www.w3.org/TR/html4/strict.dtd">

    >


    My statement is correct.

    > However, HTML 4.01 Strict is not required for a UA to use Standards
    > Compliance Mode instead of Quirks/Compatibility Mode; including the
    > system identifier suffices.


    True, a strict doctype does not guarantee that you page will be handled
    by the UA in Standards Compliance Mode either, but starting with the
    HTML 4.01 Strict is a start.

    >
    > See http://quirksmode.org/
    >
    >
    > F'up2 alt.html


    On a thread that basically dealt with the topic of *JavaScript* and one
    comment that deals with the HTML portion of the topic and you screw with
    the follow up... It is really annoying with your willy-nilly habit of
    redirecting follow ups to truncate threads, and have them pop in and out
    of NGs. Yes, redirect when the topic is really OT for the group and
    appears to have more discussion to follow, else just leave it alone
    would you.

    F'up2 restored to alt.html and comp.lang.javascript

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, May 18, 2008
    #9
  10. Jonathan N. Little wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> Jonathan N. Little wrote:
    >>> sheldonlg wrote:
    >>>> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    >>>> "http://www.w3.org/TR/html4/loose.dtd">
    >>>> <html>
    >>>> <head>
    >>>> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    >>>>
    >>>> (www.sheldonlg.com/JSstops7.htm)
    >>>>
    >>>> and it still exhibits the broken behavior of not expanding past the
    >>>> first nested table. So, it isn't the "XHTML", nor the "strict". Also,
    >>>> it isn't "quirks mode" since this is now straight html4.
    >>> No

    >> Yes, it is not XHTML, and it is not HTML 4.01 Strict. Yes, it is HTML 4.
    >>
    >>> that's a transitional doctype, strict is:

    >> http://hsivonen.iki.fi/wannabe/

    >
    > Excuse me, and this is applicable th whom?


    Pick a number.

    >>> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
    >>> "http://www.w3.org/TR/html4/strict.dtd">

    >
    > My statement is correct.


    No, it isn't. sheldonlg's statement was: "So, it isn't the "XHTML", nor the
    "strict". Also, it isn't "quirks mode" since this is now straight html4."
    This statement is correct; you have denied that, which is incorrect.

    >> However, HTML 4.01 Strict is not required for a UA to use Standards
    >> Compliance Mode instead of Quirks/Compatibility Mode; including the
    >> system identifier suffices.

    >
    > True, a strict doctype does not guarantee that you page will be handled
    > by the UA in Standards Compliance Mode either, but starting with the
    > HTML 4.01 Strict is a start.


    That is not what I was saying.

    >> See http://quirksmode.org/
    >>
    >>
    >> F'up2 alt.html

    >
    > On a thread that basically dealt with the topic of *JavaScript*


    But this subthread does not.

    > [...] Yes, redirect when the topic is really OT for the group and


    The quirks of HTML and the Trident layout engine are off-topic here.

    > appears to have more discussion to follow, else just leave it alone
    > would you.


    If someone had not mindlessly crossposted from outside Usenet, there would
    have been no need to set Followup-To to the most appropriate newsgroup for
    this subthread which happens to be outside Usenet.

    > F'up2 restored to alt.html and comp.lang.javascript


    You don't know what F'up2 means.


    Score adjusted, F'up2 alt.html again

    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
     
    Thomas 'PointedEars' Lahn, May 18, 2008
    #10
  11. VK

    VK Guest

    On May 19, 5:48 pm, sheldonlg <sheldonlg> wrote:
    > sheldonlg wrote:
    > > VK wrote:

    >
    > >> No, it is not a minimum case: there is still plenty of extra stuff
    > >> floating around. For example do not use the current CSS file, just
    > >> load the page w/o styling: and the problem goes away. So either
    > >> something sneaky in your CSS rules, or some particular CSS rule acting
    > >> strange for IE6 with malformed tables. Keep cleaning up. For the
    > >> starter make a page loading an empty CSS file and then start adding
    > >> ruleset by ruleset from the current CSS checking the behavior after
    > >> each modification.

    >
    > > I have reduced things significantly to the point where just about any
    > > change I make causes the behavior to disappear. It is in
    > >www.sheldonlg.com/JSstops.htm.

    >
    > > In this one even changing some text causes it to expand all the way????
    > > The css is as basic as I could pare it down do and still have the
    > > strange behavior in IE6:

    >
    > > #header { padding: 2%; }
    > > #onebar padding: 2% 50px 2% 50px; }
    > > .exclude_form_class {visibility: hidden;}
    > > * html .exclude_form_class {position:absolute;}

    >
    > In fact, I was able to trim it even a little further and put the css
    > into the single file www.sheldonlg.com/JSstops.htm. I moved the top:
    > 350px; into the css area as well.
    >
    > So, with this straightforward-looking file can anyone see why it doesn't
    > expand further than one nested table?


    The last sample you posted expands just fine three levels down - both
    Firefox and IE6, so this time you passed the "minimum case point" :)

    > Essentially ANY change to the
    > file, even text, causes it to expand all the way to the third nested table.


    That normally means that the source contains several errors and UA's
    dirt tolerance exploits at once - so it is like a pack of springs,
    touch one side and it starts the avalanche.
    Maybe IE6 is sensitive to display changes inside of table cells, maybe
    it chocks on position:absolute for nested tables - I don't know. I
    never made layouts like that so I cannot tell at a glance. Did you try
    to use the regular way with table under table under table with margin-
    left changing so to keep the indentation growing?
     
    VK, May 19, 2008
    #11
  12. VK

    BootNic Guest

    sheldonlg <sheldonlg> wrote in news:ZI2dncLHiYZJ5azVnZ2dnUVZ_g-
    :

    > VK wrote:
    >
    >> No, it is not a minimum case: there is still plenty of extra stuff
    >> floating around. For example do not use the current CSS file, just
    >> load the page w/o styling: and the problem goes away. So either
    >> something sneaky in your CSS rules, or some particular CSS rule acting
    >> strange for IE6 with malformed tables. Keep cleaning up. For the
    >> starter make a page loading an empty CSS file and then start adding
    >> ruleset by ruleset from the current CSS checking the behavior after
    >> each modification.

    >
    > I have reduced things significantly to the point where just about any
    > change I make causes the behavior to disappear. It is in
    > www.sheldonlg.com/JSstops.htm.
    >
    > In this one even changing some text causes it to expand all the way????
    > The css is as basic as I could pare it down do and still have the
    > strange behavior in IE6:
    >
    > #header { padding: 2%; }
    > #onebar padding: 2% 50px 2% 50px; }
    > .exclude_form_class {visibility: hidden;}
    > * html .exclude_form_class {position:absolute;}


    This is not a javascript issue, it is a style issue.

    The issue is the visibility:hidden; it dose not remove exclude_from_class,
    it just hides it. It is above the other content.

    Remove the visibility:hidden; give it a background-color and you will see
    what is taking place. Adding back visibility:hidden just hides the issue.

    Any one of the following may work.

    1. For IE you may give exclude_form_class a z-index:-1;
    2. Give images position:relative: z-index:100;
    3. Use display:none; rather then visibility:hidden;

    Some of your other examples also has a similar issue in IE7 depending on
    the width of the window.

    --
    BootNic Monday May 19, 2008 10:29 AM
    When I was young, I was put in a school for retarded kids for two
    years before they realized I actually had a hearing loss...and they
    called ME slow!
    *Kathy Buckley*
     
    BootNic, May 19, 2008
    #12
  13. VK

    VK Guest

    On May 19, 7:06 pm, sheldonlg <sheldonlg> wrote:
    > VK wrote:
    > > On May 19, 5:48 pm, sheldonlg <sheldonlg> wrote:
    > >> sheldonlg wrote:
    > >>> VK wrote:
    > >>>> No, it is not a minimum case: there is still plenty of extra stuff
    > >>>> floating around. For example do not use the current CSS file, just
    > >>>> load the page w/o styling: and the problem goes away. So either
    > >>>> something sneaky in your CSS rules, or some particular CSS rule acting
    > >>>> strange for IE6 with malformed tables. Keep cleaning up. For the
    > >>>> starter make a page loading an empty CSS file and then start adding
    > >>>> ruleset by ruleset from the current CSS checking the behavior after
    > >>>> each modification.
    > >>> I have reduced things significantly to the point where just about any
    > >>> change I make causes the behavior to disappear. It is in
    > >>>www.sheldonlg.com/JSstops.htm.
    > >>> In this one even changing some text causes it to expand all the way????
    > >>> The css is as basic as I could pare it down do and still have the
    > >>> strange behavior in IE6:
    > >>> #header { padding: 2%; }
    > >>> #onebar padding: 2% 50px 2% 50px; }
    > >>> .exclude_form_class {visibility: hidden;}
    > >>> * html .exclude_form_class {position:absolute;}
    > >> In fact, I was able to trim it even a little further and put the css
    > >> into the single file www.sheldonlg.com/JSstops.htm. I moved the top:
    > >> 350px; into the css area as well.

    >
    > >> So, with this straightforward-looking file can anyone see why it doesn't
    > >> expand further than one nested table?

    >
    > > The last sample you posted expands just fine three levels down - both
    > > Firefox and IE6, so this time you passed the "minimum case point" :)

    >
    > Hmmm. It doesn't for me. In fact, after going to about:blank, deleting
    > cookies and temp files, exiting IE and coming back in it still did not
    > expand past the first level.
    >
    > Could it simply be a browser setting?
    >
    > Previously, did it stop for you at some level?


    IE 6.0.2900.2180 / JScript 5.6.8834 / Windows XP SP2

    http://www.sheldonlg.com/JSstops.htm
    Expands up to "Purchase Supplier" and back w/o any problems.

    http://www.sheldonlg.com/JSstops8.htm
    Doesn't go further than the second level

    I still think you have to redesign the thole approach - it is too much
    dirt tolerance dependent. I don't mean you have to make all tables
    being visible at once. Keep the top one visible but others
    display:none, just set margin-left values:

    [table 1]
    [table 2]
    [table 3]
    [table 4]
     
    VK, May 19, 2008
    #13
  14. VK

    BootNic Guest

    sheldonlg <sheldonlg> wrote in
    news::

    > BootNic wrote:
    >> sheldonlg <sheldonlg> wrote in news:ZI2dncLHiYZJ5azVnZ2dnUVZ_g-
    >> :

    [snip]
    >>> #header { padding: 2%; }
    >>> #onebar padding: 2% 50px 2% 50px; }
    >>> .exclude_form_class {visibility: hidden;} * html .exclude_form_class
    >>> {position:absolute;}

    >>
    >> This is not a javascript issue, it is a style issue.
    >>
    >> The issue is the visibility:hidden; it dose not remove
    >> exclude_from_class, it just hides it. It is above the other content.
    >>
    >> Remove the visibility:hidden; give it a background-color and you will
    >> see what is taking place. Adding back visibility:hidden just hides
    >> the issue.
    >>
    >> Any one of the following may work.
    >>
    >> 1. For IE you may give exclude_form_class a z-index:-1;
    >> 2. Give images position:relative: z-index:100;
    >> 3. Use display:none; rather then visibility:hidden;
    >>
    >> Some of your other examples also has a similar issue in IE7 depending
    >> on the width of the window.

    >
    > No, z-index won't do. I want to have that block NOT be visible at all
    > until the user clicks a button (not shown in this sample app) to
    > change it style to visible. At that point it should appear at a fixed
    > position on the screen -- regardless of scrolling the rest of the
    > document -- and appear above the rest of the document. Using display:
    > hide will cause it to fit itself into wherever it was clicked. Also,
    > it is not an inline block. There are multiple places in the (real)
    > document that invoke it to appear. So, the proper setting is
    > "visibility".


    visibility:hidden; the element still takes up space, holds the position,
    it's just hidden. The issue is that it is on top of the image you wish to
    be clicked, and you can't click through exclude_form_class to the image.

    > The only reason that the block is even here in this sample code is
    > that removing it causes the "+" to expand to all four levels of
    > nesting. Of course, other things in this sample app do that as well,
    > such as removing the 'caption" stuff or even changing some text.


    So you change the content, all that does is change where you clickable
    image is. The issue remains, when exclude_form_class is over a clickable
    image, the image is not clickable.

    For the purpose of this issue remove visibility:hidden from
    exclude_form_class class, assign a background-color, now keep in mind that
    visibility:hidden; does not remove the element from the flow of the
    document, it still takes up space. The only thing this will do is allow you
    to see the issue. The issue is the same regardless of visibility
    hidden/visible.

    Until you can comprehend the issue, there is no hope for a resolution.

    --
    BootNic Monday May 19, 2008 12:28 PM
    All things come to him who waits - provided he knows what he is
    waiting for.
    *Woodrow T. Wilson*
     
    BootNic, May 19, 2008
    #14
  15. VK

    BootNic Guest

    sheldonlg <sheldonlg> wrote in
    news::

    > BootNic wrote:
    >> sheldonlg <sheldonlg> wrote in
    >> news::

    [snip]
    >> visibility:hidden; the element still takes up space, holds the
    >> position, it's just hidden. The issue is that it is on top of the
    >> image you wish to
    >> be clicked, and you can't click through exclude_form_class to the
    >> image.

    >
    > I think I see now what you are saying. So, if I understand you
    > correctly, I can still keep the visibility as "hidden" (because I want
    > it to appear in the same spot no matter which of the many buttons is
    > clicked to make it visible), but to give it a z-index of "-1". Then,
    > when made visible, also change the z-index to "100". When hiding it
    > again, also change the z-index back to "-1". That way it will appear
    > on top when I want, but will not be "clicked through" when hidden. Do
    > I understand you clearly now?


    You could keep visibility:hidden, but display:none would be better.

    If you are setting a position fixed/absolute, then all visibility:hidden
    does is take up space, you can toggle display and have the same effect
    without taking up space when it's not shown, and therefore no need to
    toggle z-index. The position will remain the same regardless if it's
    display:none or visibility:hidden, just one takes up space and the other
    does not.

    [snip]

    --
    BootNic Monday May 19, 2008 1:15 PM
    A well-developed sense of humor is the pole that adds balance to
    your step as you walk the tightrope of life
    *William Arthur Ward*
     
    BootNic, May 19, 2008
    #15
  16. VK

    VK Guest

    On May 19, 8:28 pm, sheldonlg <sheldonlg> wrote:
    > What do you mean by "dirt tolerance dependent"? This app validates
    > perfectly in W3C. (Remember that I am a php/application/back-end
    > programmer and JS and CSS are relatively new to me).


    I did not mean an offense. Yet table manipulations in fact is not a
    rocket science and aside of "display" property values glitch between
    different browsers it is pretty straightforward with browsers
    instructed to get as much as they can from the provided source. Here
    for instance a rather nasty test with multiple tbodies:
    http://transmodal.sourceforge.net/tmp/table_torture.html
    Opera gets funny on rendering but still functional, IE6, FF and Sa are
    just fine.
    I was peering again at your current test cases and still couldn't find
    an obvious reason of such strange IE6 behavior.
     
    VK, May 19, 2008
    #16
  17. VK wrote:
    > [...] Yet table manipulations in fact is not a rocket science and aside
    > of "display" property values glitch between different browsers it is
    > pretty straightforward with browsers instructed to get as much as they
    > can from the provided source. Here for instance a rather nasty test with
    > multiple tbodies:
    > http://transmodal.sourceforge.net/tmp/table_torture.html Opera gets funny
    > on rendering but still functional, IE6, FF and Sa are just fine.


    Given that a table may have more than one `tbody' element per Specification,
    Opera 9.27's behavior is simply a bug and unlikely to be the result of
    built-in error correction.

    You should make improvements on your test cases if you want them to be
    reliable. This one is not even Valid to begin with, and I don't mean the
    multiple TBODY elements (obviously). Press Ctrl+Alt+V in Opera, go to
    http://validator.w3.org/ otherwise.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, May 19, 2008
    #17
  18. VK

    VK Guest

    On May 19, 11:06 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > VK wrote:
    > > [...] Yet table manipulations in fact is not a rocket science and aside
    > > of "display" property values glitch between different browsers it is
    > > pretty straightforward with browsers instructed to get as much as they
    > > can from the provided source. Here for instance a rather nasty test with
    > > multiple tbodies:
    > >http://transmodal.sourceforge.net/tmp/table_torture.htmlOpera gets funny
    > > on rendering but still functional, IE6, FF and Sa are just fine.

    >
    > Given that a table may have more than one `tbody' element per Specification,
    > Opera 9.27's behavior is simply a bug and unlikely to be the result of
    > built-in error correction.


    It is a valid usage of the Table DOM - simply no one ever used it
    widely because very a very few of people know that a single table can
    have N amount of bodies. So more probability that some producers
    simply skipped on implementing full QA-tested blocks for that. One
    "laziness goptcha" victim is here: Opera :)

    > You should make improvements on your test cases if you want them to be
    > reliable. This one is not even Valid to begin with, and I don't mean the
    > multiple TBODY elements (obviously). Press Ctrl+Alt+V in Opera, go to http://validator.w3.org/otherwise.


    Oh, who cares of this old guiser. It endlessly complains on anything
    new what happened in the Web over the last ten years. I am still too
    young to come listen an old man mumbling complains on how the world
    became bad - especially from an electronic one :)
     
    VK, May 19, 2008
    #18
  19. VK

    VK Guest

    > > go to http://validator.w3.org/otherwise
    >
    > Oh, who cares of this old guiser. It endlessly complains on anything
    > new what happened in the Web over the last ten years. I am still too
    > young to come listen an old man mumbling complains on how the world
    > became bad - especially from an electronic one :)


    Yet OK, a bit of respect to the ol' man. I placed the caption where it
    makes him all green-happy :)
    http://transmodal.sourceforge.net/tmp/table_torture.html
    (reload to see)

    doesn't help to Opera too much though.
     
    VK, May 19, 2008
    #19
  20. VK

    BootNic Guest

    VK <> wrote in news:dac37d32-efe3-4e0d-8378-
    :

    >> > go to http://validator.w3.org/otherwise

    >>
    >> Oh, who cares of this old guiser. It endlessly complains on anything
    >> new what happened in the Web over the last ten years. I am still too
    >> young to come listen an old man mumbling complains on how the world
    >> became bad - especially from an electronic one :)

    >
    > Yet OK, a bit of respect to the ol' man. I placed the caption where it
    > makes him all green-happy :)
    > http://transmodal.sourceforge.net/tmp/table_torture.html
    > (reload to see)
    >
    > doesn't help to Opera too much though.
    >


    <col span="1000" width="*">

    What should a ua do when there are less then 1000 columns?

    --
    BootNic Monday May 19, 2008 5:11 PM
    The more you find out about the world, the more opportunities there
    are to laugh at it.
    *Bill Nye*
     
    BootNic, May 19, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ivor O'Connor
    Replies:
    4
    Views:
    947
    Isofarro
    Nov 25, 2003
  2. Peter Mount
    Replies:
    4
    Views:
    1,007
    Peter Mount
    Jan 31, 2006
  3. Beauregard T. Shagnasty

    Re: JS Stops working in IE6

    Beauregard T. Shagnasty, May 17, 2008, in forum: HTML
    Replies:
    1
    Views:
    374
    Beauregard T. Shagnasty
    May 17, 2008
  4. VK
    Replies:
    1
    Views:
    400
  5. Pugi!
    Replies:
    0
    Views:
    264
    Pugi!
    Feb 5, 2007
Loading...

Share This Page