hide and show text

[Michael Skind]

Hello,

I use a simple Table :
<TABLE>
<TR 1>
<TD></TD>
</TR>
<TR 2>
<TD></TD>
</TR>
<TR 3>
<TD></TD>
</TR>
</TABLE>
and I would like to hide the second TR when the page load in order to show
it on an image click.

I would like to avoid document.write() method.
I have tried hiden/visibility style but I get spaces where TR 2 is suppose
to be between TR 1 and TR 3.

Is there a simple way to do this ?

Thanks a lot,

M.

 

[Lasse Reichstein Nielsen]

I have tried hiden/visibility style but I get spaces where TR 2 is suppose
to be between TR 1 and TR 3.

Try setting style.display="none" to hide and style.display="" to show
it again.

/L

 

[Evertjan.]

Michael Skind wrote on 14 dec 2003 in comp.lang.javascript:

I use a simple Table :
<TABLE>
<TR 1>
<TD></TD>
</TR>
<TR 2>
<TD></TD>
</TR>
<TR 3>
<TD></TD>
</TR>
</TABLE>
and I would like to hide the second TR when the page load in order to
show it on an image click.

I would like to avoid document.write() method.

You cannot NOt avoud that,
because it woud destroy your page AND the code.

I have tried hiden/visibility style but I get spaces where TR 2 is
suppose to be between TR 1 and TR 3.

<script>
function hide(x){
document.getElementById(x).style.display='none'
}
function show(x){
document.getElementById(x).style.display=''
}
</script>


<button
onclick="hide('tr2')">
hide row 2
</button>&nbsp;

<button
onclick="show('tr2')">
show row 2
</button><br>

<table border=1>
<tr id=tr1><td>ttttt</td><td>1111111</td></tr>
<tr id=tr2><td>ttttt</td><td>222</td></tr>
<tr id=tr3><td>ttttt</td><td>3</td></tr>
</table>

 

[Thomas 'PointedEars' Lahn]

Michael Skind wrote on 14 dec 2003 in comp.lang.javascript:

You cannot NOt avoud that,
because it woud destroy your page AND the code.

Your logic is, after all, quite interesting ;-)

<script>

function hide(x){
document.getElementById(x).style.display='none'
}
function show(x){
document.getElementById(x).style.display=''
}

This is syntactically and semantically correct but error-catching

</script>
[...]

PointedEars

 

[Lasse Reichstein Nielsen]

Evertjan. wrote:

This is syntactically and semantically correct but error-catching
and inefficient. See <[email protected]> for details.

To me "error catching" is *good* (you *want* to catch your errors,
otherwise you can't fix them).

I checked the message you refer to for details, Your point is that
the author didn't check for the existence of getElementById?

The W3C DOM is the one thing I can accept not checking for. Obviously,
if you need to support older browsers (Netscape 4, IE 4), you will
need to use proprietary code, but a footnote to that effect should be
sufficient.

Anyway, the existence of document.getElementById and the style object
on the node are not sufficient to conclude that the code works. It fails
in, e.g., Opera 6, because it doesn't allow dynamic changing of the
display property.

/L

 

[Thomas 'PointedEars' Lahn]

To me "error catching" is *good* (you *want* to catch your errors,
otherwise you can't fix them).

Of course it was not meant this way.

I checked the message you refer to for details, Your point is that
the author didn't check for the existence of getElementById?

That is what `error-catching' refers to. What would be the
appropriate expression for provoking script errors with such?

The W3C DOM is the one thing I can accept not checking for. Obviously,
if you need to support older browsers (Netscape 4, IE 4), you will
need to use proprietary code, but a footnote to that effect should be
sufficient.

You could not be more wrong. W3C-DOM is supported in Windows-IE not
really (meaning it is not usable) below version 5.5 and support in
other UAs is still limited. However, it should be rule of thumb for
a Web author and J(ava)Script programmer not to exclude any people
who want to use a site, no matter how standards-compliant their UA is.
They may not have a choice.

Anyway, the existence of document.getElementById and the style object
on the node are not sufficient to conclude that the code works. It fails
in, e.g., Opera 6, because it doesn't allow dynamic changing of the
display property.

It looks like you oppose yourself, as the `display' property is part of
the W3C-DOM Level 2 Style Specification and not specified as read-only.

But thanks for pointing this out, this will save me a lot of trouble.
Can one even accomplish what the OP wants in Opera 6 and if yes, how?


PointedEars

 

[Richard Cornford]

It looks like you oppose yourself, as the `display' property
is part of the W3C-DOM Level 2 Style Specification and not
specified as read-only.

There is an apparent coincidence (but no specified or certain
relationship) that on browsers that will allow the setting of a
style.display property with JavaScript to modify the presentation of a
page the display property is typeof == 'string' while the browsers that
cannot do this either have no style object (e.g. Netscape 4) or the
display property of the style object is undefined, So:-

if((elm.style)&&(typeof elm.style.display == 'string')){
// *probably* OK to assume that setting this
// property will be reflected on the page.
}

IE 4 is an example of a browser with zero W3C DOM support that will
happily switch the display property of elements dynamically and reflect
the result in its display.

But thanks for pointing this out, this will save me a lot
of trouble. Can one even accomplish what the OP wants in
Opera 6 and if yes, how?

The dynamic aspects of Operas 5 & 6 are limited to CSS positioned
elements, which may be sized, moved and z-index stacked, but the results
suffer from numerous display bugs and are dubious at best. Given the
OP's table mark-up, Opera <= 6 will not be able to perform this task at
all. It is possible to set the style.position property of elements
dynamically so an element can be rendered position:absolute; but that
isn't going to work well (if at all) with a TR element and Opera never
re-flows the remaining content even if you do that. Otherwise,
visibility = 'hidden' would conceal the content, but not really
satisfactorily.

Richard.

 

[Eric Bohlman]

That is what `error-catching' refers to. What would be the
appropriate expression for provoking script errors with such?

"Error-prone" is the usual English idiom for "unreasonably susceptible to
errors."

I think the upshot of all this discussion is that if you're going to try to
dynamically manipulate the visibility and/or presence of elements, you need
to make them visible and displayed by default so that too much, rather than
too little, gets displayed if the browser doesn't support such
manipulation.

 

[@SM]

Thomas 'PointedEars' Lahn a ecrit :

See <[email protected]> for details.

Hello,
what do I do with that :
<[email protected]>
???
How to use it ?

Danke

 

[Richard Cornford]

Thomas 'PointedEars' Lahn a ecrit :


Hello,
what do I do with that :
<[email protected]>
???
How to use it ?

One option is to go to:-

<URL: http://groups.google.com/advanced_group_search >

and enter it (cut and paste) into the field labelled
"Message ID -- Find the message with message ID" (or as translated
into French?).

Richard.

 

[Evertjan.]

Richard Cornford wrote on 16 dec 2003 in comp.lang.javascript:

One option is to go to:-
<URL: http://groups.google.com/advanced_group_search >

or precede it [in your web browser] with:

http://www.google.com/groups?as_umsgid=

like this:

http://www.google.com/[email protected]

All posts pointing to this post:

http://www.google.com/[email protected]

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

Thomas 'PointedEars' Lahn a ecrit :


Hello,
what do I do with that :
<[email protected]>

Such a reference is particularly inconsiderate of those who use an
inferior off-line newsreader which cannot search the headers of a local
newsbase, and, being off-line, do not have immediate access to Google.

A more generally user-friendly reference would have been :
From: Thomas 'PointedEars' Lahn <[email protected]>
Newsgroups: comp.lang.javascript
Subject: Re: Works with Netscape; not IE
Date: Sun, 14 Dec 2003 01:52:48 +0100
Message-ID: <[email protected]>

 

[Lasse Reichstein Nielsen]

Such a reference is particularly inconsiderate of those who use an
inferior off-line newsreader which cannot search the headers of a local
newsbase, and, being off-line, do not have immediate access to Google.

They should still accept <which
is an official URL scheme.

Nothing will work for people being offline. A should work as
soon as they go online again.

A more generally user-friendly reference would have been :
From: Thomas 'PointedEars' Lahn <[email protected]>
Newsgroups: comp.lang.javascript
Subject: Re: Works with Netscape; not IE
Date: Sun, 14 Dec 2003 01:52:48 +0100
Message-ID: <[email protected]>

I would consider that *too* much information.

/L

 

[@SM]

"Evertjan." a ecrit :

Richard Cornford wrote on 16 dec 2003 in comp.lang.javascript:

One option is to go to:-
<URL: http://groups.google.com/advanced_group_search >

or precede it [in your web browser] with:

http://www.google.com/groups?as_umsgid=

like this:

http://www.google.com/[email protected]

Oh Yes that works fine ! Thanks
(un peu compliqué tt de même)
(not very simple simple )

 

[Dr John Stockton]

JRS: In article <[email protected]>, seen in

They should still accept <which
is an official URL scheme.

Nothing will work for people being offline.

Not so. With a newsreader such as I described, having a local newsbase
but being unable to search headers, a recent article by a given author
can readily be found by approximate subject and date.

I would consider that *too* much information.

Remember that the need is to indicate not only where it can be found,
but whether it needs to be sought. No-one remembers the message-ID of
an article; but, on seeing the above description, one may well recall
the article itself, and its approximate contents.

 

[@SM]

Dr John Stockton a ecrit :

JRS: In article <[email protected]>, seen in

Does it depent of server (relay) ?
because when I click on link above I get : ERROR message

 

[DU]

To me "error catching" is *good* (you *want* to catch your errors,
otherwise you can't fix them).

"Error catching" strongly suggests error handling with javascript try,
catch, finally coding.

I checked the message you refer to for details, Your point is that
the author didn't check for the existence of getElementById?

The W3C DOM is the one thing I can accept not checking for.

I entirely agree with you on this. If a browser does not support
document.getElementById, then I think it is not worth the trouble trying
to write more javascript code (hacks, cross-browser code) to support it.
One day, people have to upgrade their browser.

Obviously,

if you need to support older browsers (Netscape 4, IE 4), you will
need to use proprietary code, but a footnote to that effect should be
sufficient.

If a webpage is well designed, then content should degrade gracefully
and normal, basic webpage functionality should/will work in such page.
The limits I set in building webpages involve browsers which only
support document.all and document.layers.

Anyway, the existence of document.getElementById and the style object
on the node are not sufficient to conclude that the code works.

Good point! Mozilla 1.6beta and Opera 7.23 supports visibility:collapse
but the rendering obviously proves that its support is limited, incomplete.

Bug 77019: <tr style="visibility: collapse;"> looks like hidden and
collapsed
http://bugzilla.mozilla.org/show_bug.cgi?id=77019
http://bugzilla.mozilla.org/show_bug.cgi?id=76497

CSS2 17.5.5 Dynamic row and column effects
"The 'visibility' property takes the value 'collapse' for row, row
group, column, and column group elements. This value causes the entire
row or column to be removed from the display, and the space normally
taken up by the row or column to be made available for other content."
http://www.w3.org/TR/CSS2/tables.html#dynamic-effects

DU

It fails

 

[DU]

Of course it was not meant this way.




That is what `error-catching' refers to. What would be the
appropriate expression for provoking script errors with such?

error-catching in a javascript newsgroup could be referring to
try...catch...finally coding too, you know.
http://devedge.netscape.com/library/manuals/2000/javascript/1.5/reference/stmt.html#1051663

You could not be more wrong. W3C-DOM is supported in Windows-IE not
really (meaning it is not usable) below version 5.5 and support in
other UAs is still limited. However, it should be rule of thumb for
a Web author and J(ava)Script programmer not to exclude any people
who want to use a site,

That is why proper testing should be done to insure that content is
accessible without javascript. A properly designed webpage will not
prevent web-tv users, Lynx users, speech browsers, etc.. from accessing
the webpage's content and using normal standard navigation.
When designing a page, one should start with establishing the content,
then the structure, then the markup code, then the style formating and
then and only at the end the script code. And testing the webpage should
go in the reverse order (by disabling script, then stylesheet).

no matter how standards-compliant their UA is.

They may not have a choice.




It looks like you oppose yourself, as the `display' property is part of
the W3C-DOM Level 2 Style Specification and not specified as read-only.

But thanks for pointing this out, this will save me a lot of trouble.
Can one even accomplish what the OP wants in Opera 6 and if yes, how?

I know that getElementById method is supported by Opera 6 and so is CSS
property visibility. I don't know if that would work for table rows: I
doubt it.

PointedEars

If it can not be accomplished in Opera 6 (or any other UA), then it
proves that basic normal accessibility should be considered when
designing the webpage and that users should be prepared to be told, to
be invited to upgrade their browser to the latest available version.

No one started with the basic issues either, regarding the OP initial
post: what are the webpage goals, requirements, overview, what's its
context within the site, etc. We were all asked about how to implement
the visibility solution on a targeted table row. Who knows, this could
be a working solution for a badly assessed/diagnosticated problem.

DU

 

[DU]

<snip>

[snipped]

The dynamic aspects of Operas 5 & 6 are limited to CSS positioned
elements, which may be sized, moved and z-index stacked, but the results
suffer from numerous display bugs and are dubious at best. Given the
OP's table mark-up, Opera <= 6 will not be able to perform this task at
all. It is possible to set the style.position property of elements
dynamically so an element can be rendered position:absolute; but that
isn't going to work well (if at all) with a TR element and Opera never
re-flows the remaining content even if you do that. Otherwise,
visibility = 'hidden' would conceal the content, but not really
satisfactorily.

Richard.

Concealing the content would certainly be a start, an acceptable outcome
for a not-so-recent (outdated IMO) browser version. The subject line of
this thread is about hiding text.
What I strongly suspect here is that the OP's real webpage is based on
table design. Within a non-table-based webpage design, there would be
other ways to show and hide text.

DU