Script for Hiding/Un-Hiding Text On Click

[Ste]

Hi there,

I've got a website with a list of Frequently Asked Questions, so
there's a question and answer in a long list down the page.

Can anyone recommend a simple script that would allow me to hide each
answer when the page loaded, but then made them individually
appear/disappear when clicking the question?

I'm after a solution that will degrade gracefully if a page doesn't
load, i.e. unlike this example which doesn't seem to show the answers
if JavaScript is disabled (when it should actually show everything if
there's no JavaScript): http://www.virb.com/faq

Thanks for any advice on this,

Ste

[David Mark]

On Jul 20, 4:41 pm, Ste <[e-mail]:
[snip]

I did find some tutorials for jQuery and mootools, but to be honest, I
couldn't get these to work even after following the tutorials!

You certainly don't need jquery or mootools for this. And if you
don't know JS at all, you should learn a bit before attempting this.

[ASM]

En réponse à David Mark qui nous a susurré, en date du : 24/07/07 3:23,
le message sibyllin suivant :

(very long snip)

Did you test with Netscape 4 too?

Because it was said "gracefully degrade",
yes I did (NC 4.5)
and ... all OK with single if(gEBI)
....
of corse

--
Stephane Moriaux et son (moins) vieux Mac

[David Mark]

"ASM" <st*********************@wanadoo.fr.invalidwrote in message
news:46***********************@news.orange.fr...

En réponse à David Mark qui nous a susurré, en date du : 24/07/07 3:23,
le message sibyllin suivant :

(very long snip)

>Did you test with Netscape 4 too?

Because it was said "gracefully degrade",
yes I did (NC 4.5)
and ... all OK with single if(gEBI)
...
of corse

Right. Both of our solutions will work with any browser that predates
getElementById. Ironically, the other one posted, which purportedly
degraded better, would break all such browsers, including NS4.

[Randy Webb]

Richard Cornford said the following on 7/29/2007 7:20 PM:

David Mark wrote:

>On Jul 29, 12:28 pm, Richard Cornford wrote:

>>David Mark wrote:

<snip>

<snip>

>>>but what other browsers (embedded or otherwise) display
this behavior?

Pretty much all of the ones with non-dynamic DOMs. NetFont 4
,for example.

And I think it is NetFront.

It is.

> Regardless, what is that one used for?

PDAs and mobile phones

Richard, how do, or can, you identify NetFront? I have a cell phone with
a browser that has no splash/startup screen, the Manufacturer
can't/won't tell me what browser it is, and the UA string is identical
to my IE7 UA string with the exception of the .NET parts of it.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[David Mark]

On Jul 30, 2:31 am, Randy Webb <[e-mail]:

Nothing is "bullet-proof" on the Web. I can see at least five places
that the code can still fail but it is all irrelevant as you will simply

Utter nonsense. That would be rougly every other line. If your HTML
has the wrong ID syntax for questions (or no ID), that could cause a
problem, but that would hardly be the fault of the code. Sure, you
could test for that before slicing up the id to make it friendlier to
coders. I wasn't publishing an API with this example.

I guess if you run out of disk space on your PC while running the
script, that could cause unexpected results. Same for a connection
failure during the download, a power outage, etc.

[Richard Cornford]

Richard Cornford wrote:
<snip>

... the inference that what you were doing as a result of the
test was an approvers thing to be doing as a result of the test?

<snip ^^^^^^^^^

That was intended to be 'appropriate'.

Richard.

[David Mark]

On Jul 30, 5:13 pm, "Richard Cornford" <[e-mail]>
wrote:

>

[snip]

Is a PDA with a 600x800, 24 bit color display going to use a 'handheld'
style sheet just because it can be held in the hand. And without being

Some do. Some don't. I do know that Opera Mini does as that is what
I use to test handheld styles.

presented with any actual handheld style sheet might a mobile phone not
decide to use a screen media style sheet as its second choice?

I always present a handheld style.

>
Looking at the handheld style sheet definitions they seem to be aimed at
monochrome, and text matrix displays in addition to small screens. While

Not entirely. I move floated sidebars to display below the content,
show "skip to navigation" links that would otherwise be hidden by the
main (media="all") style sheet, tighten up margins, display popup
menus inline, etc.

actual mobile phone and PDA browsers are full-color, pixel graphic
displays and they usually have quite good (visual) CSS support.

Sure, but what works on a large screen is not usually optimal for the
small.
[snip]

>
Are you saying that this instance is not object inference because you
personally were not making the inference that what you were doing as a
result of the test was an approvers thing to be doing as a result of the
test?

Somewhat. I would describe the previous shortfall, which is not dealt
with as a known gap in the design logic. The design does not infer
that gEBI =dynamic display properties. The only way to make this
clear is with a comment in the code, which I should have included.

[snip]

Assuming that your theory about the handling of the media rule is
correct and a browser on a mobile phone will disregard a screen style
sheet (even though your are not explicitly presenting it with a handheld
style sheet to use it its place), what have

Okay. I should have noted that a handheld style sheet is a good idea
for use with this example (or any page for that matter.) Regardless,
some PDA's will ignore the handheld rules and use screen rules, but
not Opera 6 and hopefully not netFront.

you now done on browsers

embedded in (or just installed on) mobile phones that are capable of the
dynamic display manipulation. They pass your tests and the LINK element
is written out. Because of the media specified they ignore it, but still
go on to initialise the script that will switch the display value. The
elements then start off visible, and disappears on the user's first
click (as the display property switches from the empty string to
'none')

No, in this case, it would be the opposite effect. The first click
would show it (and it is already shown of course) and the next would
hide it. Not good either way.

A better idea than switching the inline display style would be to
switch class names. I changed the style sheet to:

#questions dd {display:none}
#questions dd.shown {display:block}

And changed the line that set the style property to:

if (el) el.className = (el.className == '')?'shown':''

, and then reappears on the user's next click, toggling form then

on. That sounds like a very unintuitive (indeed rather bizarre) user
interface design.

It would be indeed. The odd thing is that Opera's handheld simulator
in Opera 9 did not work as you would expect. It wrote the style
sheet, changed the display styles on clicks (just confirmed with an
alert), but did not hide the answers. So there was a small gap in the
revision's logic and my testing was foiled by what would seem to be a
bug in Opera's Small Screen view. I never ran into that one before as
I never hide or show elements when handheld rules are in effect (eg
popup menu activators are hidden and their menus are displayed
inline.) Regardless, that works for me and is perfectly semantic as
the questions are linked to the answers' anchors.

I thought for a moment that Opera 9's Small Screen view was emulating
Opera 6's handheld behavior (with the limited DOM support), but that
can't be the case as the style sheet wouldn't be written (assuming the
test we discussed previously is valid for Opera 6.)

[David Mark]

On Jul 30, 8:38 pm, David Mark <[e-mail]:

On Jul 30, 6:33 pm, David Mark <[e-mail]:
[snip]

I suddenly realized that there is an even better solution that does
not write a style tag and does not cause any

That should read: "a media-specific style tag." And more to the
point, one that uses display:none.

[Randy Webb]

David Mark said the following on 7/30/2007 2:29 PM:

On Jul 30, 2:31 am, Randy Webb <[e-mail]:

>Nothing is "bullet-proof" on the Web. I can see at least five places
that the code can still fail but it is all irrelevant as you will simply

Utter nonsense.

What is "utter nonsense" is your belief that anything on the Web is
"bullet-proof" and your re-write of the code in question is simple proof
of that notwithstanding the fthree I still see that it can fail.

That would be rougly every other line.

I will narrow it down for you. The re-write has it down to 3 lines. And
those three lines are in the onload function. And bare in mind that this
thread has become more about feature detection than it ever will be
about hiding/showing text.

Note also that I said "can fail" and not "will fail". All three lines
fall into the "what if the UA doesn't support what you are trying to do"
category and is more of a mental exercise than anything else. Although I
can tell you that the browser in my cell phone does not support dynamic
onclicks and tabIndex. It handles them fine if code in the HTML though.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

David Mark wrote:

>On Jul 22, 9:13 pm, Richard Cornford wrote:

>>David Mark wrote:
Except your CSS is invalid!
That is very questionable. The CSS specs mandate the
handling of unrecognised property names and values
(they are to be ignored in all cases, which IE fails
to do) and so the question arises as to why it is
necessary to mandate the handling of unrecognised
properties and values if a notion of validity is
attached that precludes their appearing in the first
place.

According to the w3c validator and the error consoles of
various browsers, it is invalid.

Not unless you can establish that the concept of validity attaches to
the use of unrecognised property names or value. If the concept
attaches then why does the specification mandate the handling of
unrecognised property names and values, as they would be precluded in
any 'valid' source? The behaviour of w3c 'validator' is not, in itself,
sufficient to indicate that the concept of validity can be applied here.

The specification includes that provision so that parsing would not fail
entirely on unknown syntax, properties and property values, which do not
need to be proprietary for that; it is not sanctioning the use of the
former. But that discussion belongs in another newsgroup.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[David Mark]

On Jul 31, 4:33 am, Randy Webb <[e-mail]:
[snip]

>
I will narrow it down for you. The re-write has it down to 3 lines. And
those three lines are in the onload function. And bare in mind that this
thread has become more about feature detection than it ever will be
about hiding/showing text.

No kidding.

>
Note also that I said "can fail" and not "will fail". All three lines

I suppose virtually anything "can fail."

fall into the "what if the UA doesn't support what you are trying to do"
category and is more of a mental exercise than anything else. Although I

I'm pretty sure I know what you are driving at. Like if gEBTN is an
empty placeholder and returns null instead of an array. Or if the
style property of an element is not an object, etc. Okay, but I am
not adding any more bloat to what was originally supposed to be a
simple example. I think my last description of it was "pretty bullet-
proof", which doesn't mean 100% guaranteed to work in every browser
and device that has come out since 1995.

can tell you that the browser in my cell phone does not support dynamic
onclicks and tabIndex. It handles them fine if code in the HTML though.

It also does not support updating display properties, so the answers
appear from the start and all should be well. You did mention that
your version of an earlier example worked on your phone for just this
reason.

And bear in mind that I stated a while back that I wouldn't recommend
doing this with a simple FAQ in the first place. Furthermore, I don't
recommend showing/hiding elements at all when handheld style rules are
in effect. I explained how to achieve this with the more appropriate
example of popup menu lists a few posts back.

[Randy Webb]

David Mark said the following on 7/31/2007 7:44 PM:

On Jul 31, 4:33 am, Randy Webb <[e-mail]:

<snip>

>can tell you that the browser in my cell phone does not support dynamic
onclicks and tabIndex. It handles them fine if code in the HTML though.

It also does not support updating display properties, so the answers
appear from the start and all should be well. You did mention that
your version of an earlier example worked on your phone for just this
reason.

It was more of a mental note than anything else. Not a lot to do with
the particular script at hand. I didn't find out it doesn't support
dynamic onclicks until I was working on something for work today and
tested it and discovered it wouldn't add them. That is when I started
testing some more to see what it did and didn't support.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/