JS Stops working in IE6

BootNic wrote:

sheldonlg <sheldonlg> wrote in
news:C92dnYGdeef5CKzVnZ2dnUVZ_obinZ2d (AT) giganews (DOT) com:

BootNic wrote:
sheldonlg <sheldonlg> wrote in news:ZI2dncLHiYZJ5azVnZ2dnUVZ_g-
dnZ2d (AT) giganews (DOT) com:
[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.

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?

I tried this on the sample app by putting z-index: -1 in the class
exclude_form_class (see www.sheldonlg.com/JSstops9.htm) and it expanded
all the way.

Note: In the real app (not this sample) that section is to appear as a
"position: fixed". Of course, IE6 doesn't know how to handle
"position:fixed", so there are workarounds to make it happen that I am
using (margin-left:auto; margin-right:auto).

I am going to make these changes in the real app. An early thank you
BootNic, and a thank you also to VK for your efforts and to all the
others who tried to help.

sheldonlg <sheldonlg> wrote in
news:2fSdncrzhOGcMqzVnZ2dnUVZ_o3inZ2d (AT) giganews (DOT) com:

BootNic wrote:
sheldonlg <sheldonlg> wrote in
news:C92dnYGdeef5CKzVnZ2dnUVZ_obinZ2d (AT) giganews (DOT) com:
[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 wrote:

sheldonlg <sheldonlg> wrote in
news:2fSdncrzhOGcMqzVnZ2dnUVZ_o3inZ2d (AT) giganews (DOT) com:

BootNic wrote:
sheldonlg <sheldonlg> wrote in
news:C92dnYGdeef5CKzVnZ2dnUVZ_obinZ2d (AT) giganews (DOT) com:
[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]

I just tried it on my real app and it worked perfectly. I thank you so
very much. This has been dogging me for over a month now. It was the
last bug (until new ones are found :-) ) that I had to fix.

With 20-20 hindsight, the problem/solution was so obvious that I can
kick myself for not seeing it.

Thanks.

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/tm...e_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 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/tm...e_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$8300dec7 (AT) news (DOT) demon.co.uk>

On May 19, 11:06 pm, Thomas 'PointedEars' Lahn <PointedE... (AT) web (DOT) de>
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/tm...ture.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 :-)

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/tm...e_torture.html
(reload to see)

doesn't help to Opera too much though.

VK <schools_ring (AT) yahoo (DOT) com> wrote in news:dac37d32-efe3-4e0d-8378-
0fbd1337851f (AT) 26g2000hsk (DOT) googlegroups.com:

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/tm...e_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*

On May 20, 1:11 am, BootNic <bootnic.bou... (AT) gmail (DOT) com> wrote:

col span="1000" width="*"

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

Same as with 999 columns left if only <col span="1" width="100">
provided or with .foobar ruleset if not a single foobar class is
presented: nothing.
col is not an element to render, it is a preliminary instruction how
to treat certain types of elements if they will be further presented
in the container.