hiding/showing a section of a page

[ashkaan57]

Hi,
how can I hide / show a section of a page when a link is clicked?

Click on "show section" would show the section and change the link to
"hide section", clicking on "hide section" would hide it.

TIA.

 

[Craig Keightley]

in its simplest form:
create a div tag on your html page
with a button / link, use the onClick method to call a function
in the function use document.write to the div tag
to hide set the div tag to '' using document.write

 

[enrique]

Is this an IE-specific solution?

 

[ashkaan57]

Hi Craig,
thanks a lot for the reply. Is it possible to give me a simple code
sample? Somthing that would work with IE and NN? TIA.

 

[Mick White]

in its simplest form:
create a div tag on your html page
with a button / link, use the onClick method to call a function
in the function use document.write to the div tag
to hide set the div tag to '' using document.write

No, no, no. Manipulate the div's style "display" property, or its
"visibility" property.
Mick

 

[ashkaan57]

Thanks for the reply.
I used the following code and I thought it was working (at least on
netscape and firefox) unitl I tested it with IE, wehere it chokes:

<style>
..noshow {
display: none;
}
..menu {
display: block;
}
</style>

<script language="javascript>
if (document.getElementById)
{
function getElemById(id)
{
return document.getElementById(id);
}
}
else if (document.all)
{
function getElemById(id)
{
return document.all(id);
}
}
else if (document.layers)
{
function getElemById(id)
{
return document.layers[id];
}
}

function hide(ele)
{
getElemById(ele).className = "noshow";
}

function show(ele)
{
getElemById(ele).className = "menu";
}
</script>

Then in the html part:

<a href="javascript:show('category');">Show Categories</a>

<div id="category" class="noshow">
....
....
<a href="javascript:hide('category');">Hide Categories</a>
</div>

In IE, I get: "Error: document.layers is null or not an object"

 

[Richard Cornford]

Thanks for the reply.
I used the following code and I thought it was
working (at least on netscape and firefox) unitl
I tested it with IE, wehere it chokes:

It will not work on Opera either, and should not be expected to work on
any ECMAScript implementation.

<script language="javascript>

It is best to use formally valid HTML if you intend to script an HTML
document.

if (document.getElementById)
{
function getElemById(id)
{
return document.getElementById(id);
}
}

ECMAScript does not have conditional function declarations.

<snip>

Ahh, top posting. If you don't want you questions answered it would be
more efficient to just no ask them.

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>, dated Sun, 29
May 2005 13:24:31, seen in Richard Cornford

ECMAScript does not have conditional function declarations.

But

if (A) eval("function B() { return 3 }")

seems to give the effect, though.

Therefore, ISTM that <FAQENTRY> 4.40 needs an addition, since the case

<snip>

Ahh, top posting. If you don't want you questions answered it would be
more efficient to just no ask them.

FAQ 2.3 uses the term "top post", which should be "top-post", without
defining it. In another newsgroup I've seen a whole thread led astray
by the difference between a "top poster" (a windbag, for example) and a
"top-poster" (a misformatter); and then there is also the meaning akin
to that might be expressed by answering "name a top author" by JKR.

 

[Lasse Reichstein Nielsen]

JRS: In article <[email protected]>, dated Sun, 29
May 2005 13:24:31, seen in Richard Cornford
<[email protected]> posted :

But

if (A) eval("function B() { return 3 }")

seems to give the effect, though.

Indeed, and, if I read ECMA262v3 correctly, it should always work.
The argument of "eval" is parsed as a Program, which may include
function declarations, and the variables object of the evaluation
context is the same as for the call to "eval".

/L

 

[Richard Cornford]

Richard Cornford posted :

But

if (A) eval("function B() { return 3 }")

seems to give the effect, though.

Therefore, ISTM that <FAQENTRY> 4.40 needs an addition, since
the case is not covered there </FAQENTRY>.

<snip>

The eval function goes through variable instantiation in the execution
context from which it is invoked (Just one of its necessary overheads).
So yes, the effect is a function declaration that will add (or replace)
a named property of the execution context's Variable object with a
reference to a new function object.

If there was some significant difference between a function object
created with a function declaration and a function object created with a
function expression then maybe this would be worth considering for some
applications. But there is no significant difference between the two, so
the conditional evaluation of a function expression, and the assignment
of the result to a local variable, will have an effect indistinguishable
from the suggested - eval - call, and without the overheads involved in
the invocation of the eval function.

As there is a more efficient and more direct alternative to this -
eval - use it cannot be proposed as a valid application of the eval
function.

An observation about the action of this evaled function declaration is
that if the execution context's scope chain has been augmented through
the use of the - with - statement, such as:-

with( {B:null) ){
if (A) eval("function B() { return 3 }")
}

- The object with the null 'B' property will be at the top of the new
function's [[Scope]] scope chain, but variable instantiation is
specified as acting on the Variable object of the containing execution
context, so the resulting 'B' function object is inaccessible on its own
scope chain. I cannot think of any advantage in creating such a
structure (and a similar effect could be achieved if the function's body
declared a 'B' local variable).

Richard.

 

[Michael Winter]

JRS: In article <[email protected]>, dated Sun, 29
May 2005 13:24:31, seen in Richard Cornford
<[email protected]> posted :
[snip]

ECMAScript does not have conditional function declarations.

But

if (A) eval("function B() { return 3 }")

seems to give the effect, though.

Yes it does, but it's not necessary. I think the subtlety in Richard's
post might be lost on the OP: ECMAScript does not have conditional
function declarations, but function expressions can be used in a manner
that allows the conditional creation of function objects.

Therefore, ISTM that [FAQ] 4.40 needs an addition, since the case
is not covered there.

I don't think it's worth covering. I can't see any benefit of using this
rather than function expressions as the eval argument won't parsed until
eval itself is called (thereby losing the pre-execution evaluation
advantage that declarations provide).

The only use of eval I have to date is the emulation of the
Function.prototype.apply/call methods. The traditional approach is to
use a switch statement that calls the this value differently based on
the number of arguments, but that becomes impractical if a large or
unknown number of arguments may be required. Using eval, the result may be:

var global = this;

Function.prototype.apply = function(object, args) {
var property = ' $apply', result, undef;

if(null == object) {object = global;}
if(null == args) {args = [];}

while('undefined' != typeof object[property]) {
property += property;
}
object[property] = this;

if(!args.length) {
result = object[property]();
} else {
for(var i = 0, n = args.length, t = new Array(n); i < n; ++i) {
t = i;
}
result = eval('object[property](args['
+ t.join('], args[')
+ '])');
}
object[property] = undef;

return result;
};

I dislike that though: it just seems generally ugly. If there are better
suggestions, I'd welcome them (particularly with performance, which I
haven't really looked into yet).

[snip]

Mike

 

[Michael Winter]

JRS: In article <[email protected]>, dated Sun,
29 May 2005 13:24:31, seen in Richard
Cornford <[email protected]> posted :
[snip]

ECMAScript does not have conditional function declarations.

But

if (A) eval("function B() { return 3 }")

seems to give the effect, though.

Yes it does, but it's not necessary. I think the subtlety in Richard's
post might be lost on the OP: ECMAScript does not have conditional
function declarations, but function expressions can be used in a manner
that allows the conditional creation of function objects.

Therefore, ISTM that [FAQ] 4.40 needs an addition, since the case is
not covered there.

I don't think it's worth covering. I can't see any benefit of using this
rather than function expressions.

The only use of eval I have to date is the emulation of the
Function.prototype.apply/call methods. The traditional approach is to
use a switch statement that calls the this value differently based on
the number of arguments, but that becomes impractical if a large or
unknown number of arguments may be required. Using eval, the result may be:

var global = this;

Function.prototype.apply = function(object, args) {
var property = ' $apply', result, undef;

if(null == object) {object = global;}
if(null == args) {args = [];}

while('undefined' != typeof object[property]) {
property += property;
}
object[property] = this;

if(!args.length) {
result = object[property]();
} else {
for(var i = 0, n = args.length, t = new Array(n); i < n; ++i) {
t = i;
}
result = eval('object[property](args['
+ t.join('], args[')
+ '])');
}
object[property] = undef;

return result;
};

I dislike that though: it just seems generally ugly. If there are better
suggestions, I'd welcome them (particularly with performance, which I
haven't really looked into yet).

[snip]

Mike

 

[Richard Cornford]

Michael Winter wrote:

The only use of eval I have to date is the emulation of
the Function.prototype.apply/call methods. ...

I dislike that though: it just seems generally ugly.
If there are better suggestions, I'd welcome them
(particularly with performance, which I haven't
really looked into yet).

There are two aspects to the apply/call emulation. There is the
theoretical emulation that should satisfy the ECMA 262 specified
behaviour, and so must (at some point) use eval because it is not
possible to tell how many arguments may be used with the methods. Then
there is the application of an apply/call emulation in real code, where
is it possible to know the maximum number of arguments actually used.
The real world emulation does not need to use eval at all, because it
can be hard-coded to provide only the level of emulation needed. And in
doing that an obvious performance gain is achieved.

When I first became interested in apply emulation my first though was to
provide a full emulation, and I argued with Douglas Crockford on the
subject. But with experience of using apply emulations I have come to
the conclusion that Douglas's proposed design best suites the task. He
uses - switch - on the arguments length, with support for limited
arguments, and then puts an alert in the - default - clause to tip the
developer off that the emulation needs extending in the event that it is
not handling enough arguments in its context of use.

In reasonably designed code very few functions/methods have more than a
couple of formal parameters, and only a small proportion of
functions/methods are ever used with apply/call.

If, for example, apply/call are only used for event handler stacking
then the emulation only needs to cope with one argument.

Richard.

 

[RobG]

Thanks for the reply.
I used the following code and I thought it was working (at least on
netscape and firefox) unitl I tested it with IE, wehere it chokes:

<style>

The type attribute is required:

<style type="text/css">

But you don't really need to use classnames for this exercise.

[...]

<script language="javascript>

Richard was suggesting that you drop the depreciated language attribute
and include the required type attribute:

if (document.getElementById)
{
function getElemById(id)
{
return document.getElementById(id);
}

Not much point in attempting replace a function with itself - if
getElementById is supported (which is likely more than 95% of browsers
in use on the web), just leave well enough alone. If all you want to
do is provide an alternative for browsers that don't support
finding an element using getElementById, then test for them explicitly.

And though Richard pointed out that you can't have conditional function
declarations, you can conditionally declare a function:

if ( !document.getElementById ) {
if ( document.all ) {
document.getElementById = function(id) {
return document.all[id];
}
} else if ( document.layers ) {
document.getElementById = function(id) {
return document.layers(id);
}
} else {
document.getElementById = function(id) {
return null;
}
}
}

The above does not support all the features of getElementById, but
should be sufficient for simple calls.

[...]

function hide(ele)
{
getElemById(ele).className = "noshow";
}

function show(ele)
{
getElemById(ele).className = "menu";
}

Hide and show can be done in one function that just toggles between
'none' and '', which should be suitable for most situations. It's
probably useful to test that the style object is supported too:

function showHide( ele ) {
if ( ele.style )
ele.style.display = (ele.style.display == '')? 'none' : '';
}
}

In case style or javascript aren't supported, any elements that are
essential to the use of the page should be visible by default. If you
want them hidden on page load, then hide them with script using onload
or strategically placed script elements (e.g. just after each element
or group of elements that you want to hide).

[...]
Ah, there's the answer...

 

[Mick White]

[...]


Ah, there's the answer...

I was merely suggesting he not build a house with wooden nails...

Mick

 

[ashkaan57]

Thanks a lot guys, for the wealth of info. IThe problem was, as some of
you pointed out, was with my conditional function definition.

I still donlt know what is a 'top-poster' or a 'top poster'!

Have a nice day.

 

[Dag Sunde]

This is top-posted. Here the answer comes before the question.

Thanks a lot guys, for the wealth of info. IThe problem was, as some of
you pointed out, was with my conditional function definition.

I still donlt know what is a 'top-poster' or a 'top poster'!

Have a nice day.

This is bottom-posted. Here one can read your question first, and then
read my answer.

 

[Richard Cornford]

This is top-posted. Here the answer comes before the question.

And is usually followed by a verbatim quote of the previous message(s).

(e-mail address removed) wrote:

This is bottom-posted. Here one can read your question first,
and then read my answer.

The preferred posting style is 'interleaved posting', where responses
follow quoted sections of the preceding posts, trimmed down so that the
quoted section is sufficient to provide a context for the response, but
no more (with quotes attributed and edits marked).

This means removing sections of the preceding posts that are not
relevant to the response. For example, you were not responding to 'Have
a nice day", so that should have been trimmed form the quote. While I am
(effectively) responding to "Have a nice day", so I should leave it in
what I quote to provide context for my response, but remove the
irrelevant first paragraph from your quote.

The aim here is efficient communication. Responses provided in, and
with, their context, but nothing superfluous.

The FAQ for this group provides considerable detail on the subject of
post formatting.

Richard.

 

[Thomas 'PointedEars' Lahn]

ECMAScript does not have conditional function declarations.

<FAQENTRY>

However, it does have `FunctionExpression's which are supported
from JavaScript 1.2 (NN 4.0) and JScript 1.0 (IE 3.0) on:

if (document.getElementById)
{
var getElemById = function getElemById(id)
{
return document.getElementById(id);
}
}

</FAQENTRY>

So, as Richard stated correctly (but much in detail so that it may not
be obvious to the casual reader)[1], there is not really a need for evil
eval here, and the above is what the FAQ should recommend instead. See
<http://pointedears.de/scripts/dhtml.js>.


PointedEars
___________
[1] <[email protected]>