Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #17365 > unrolled thread

baffled trying to call style.display value

Back to article view | Back to comp.lang.javascript

Contents

  baffled trying to call style.display value JeffG <jeffgutsell@fuse.net> - 2012-11-27 08:08 -0800
    Re: baffled trying to call style.display value Scott Sauyet <scott.sauyet@gmail.com> - 2012-11-27 08:20 -0800
      Re: baffled trying to call style.display value Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-10 01:24 +0100
        Re: baffled trying to call style.display value Scott Sauyet <scott.sauyet@gmail.com> - 2012-12-10 05:03 -0800
          Re: baffled trying to call style.display value Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-10 16:04 +0100
            Re: baffled trying to call style.display value Scott Sauyet <scott.sauyet@gmail.com> - 2012-12-10 08:54 -0800
              Re: baffled trying to call style.display value Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-10 19:36 +0100
            Re: baffled trying to call style.display value Stefan Weiss <krewecherl@gmail.com> - 2012-12-10 22:45 +0100
              Re: baffled trying to call style.display value Andrew Poulos <ap_prog@hotmail.com> - 2012-12-11 10:19 +1100
              Re: baffled trying to call style.display value Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-11 00:34 +0100
          Re: baffled trying to call style.display value Scott Sauyet <scott.sauyet@gmail.com> - 2012-12-10 07:39 -0800
            Re: baffled trying to call style.display value Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-10 17:10 +0100
    Re: baffled trying to call style.display value Jake Jarvis <pig_in_shoes@yahoo.com> - 2012-11-27 17:33 +0100
      Re: baffled trying to call style.display value Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-27 17:49 +0100
    Re: baffled trying to call style.display value JeffG <jeffgutsell@fuse.net> - 2012-11-27 09:38 -0800
      Re: baffled trying to call style.display value Tim Streater <timstreater@greenbee.net> - 2012-11-27 17:59 +0000
        Re: baffled trying to call style.display value Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-27 21:01 +0100
          Re: baffled trying to call style.display value Tim Streater <timstreater@greenbee.net> - 2012-11-27 22:32 +0000
            Re: baffled trying to call style.display value Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-27 23:50 +0100

#17365 — baffled trying to call style.display value

I am creating a table of contents with nested UL lists. Many of the LI tags contain A tags and the UL of a lower-level list. The A tags call a function meant to show toggle display of the lower level lists.
The link passes the "this" keyword to the function, which gets the parent node and then finds the sibling UL.
For some reason, the function is unable to return the style.display value that was set by the CSS file (Loaded before the javascript). So the first time I run the function by clicking the link, my "if" test always goes to the else statement.
What am I doing wrong?
Here is the function:
function TocOpenClose(Anc) {
	var parenLI;
	var NextUL;
	parenLI = Anc.parentNode;
	NextUL = parenLI.getElementsByTagName("ul")[0];

	if (NextUL.style.display=="none")
	{
		NextUL.style.display = "block";
	}
	else
	{
		NextUL.style.display = "none";
	}
}

[toc] | [next] | [standalone]

#17366

JeffG  wrote:
> [ ... ]
> For some reason, the function is unable to return the style.display
> value that was set by the CSS file [ ... ]

`someElement.style` represents the collection of properties known to
the Javascript engine, which is, chiefly, the ones set by that
engine.  There are techniques to get the computed style of an
element.  You want to search for `getComputedStyle` and, for older
versions of IE, `currentStyle`.

The spec is at

    <http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSview-
getComputedStyle>

and MDN's page is at

    <https://developer.mozilla.org/en-US/docs/DOM/
window.getComputedStyle>

Best of luck,

  -- Scott

[toc] | [prev] | [next] | [standalone]

#17636

[Supersedes]

Scott Sauyet wrote:

> JeffG  wrote:
>> [ ... ]
>> For some reason, the function is unable to return the style.display
>> value that was set by the CSS file [ ... ]
> 
> `someElement.style` represents the collection of properties known to
> the Javascript engine, which is, chiefly, the ones set by that
> engine.

What can one say to such a mindbogglingly large amount of misinformation in 
just one sentence?  Nonsense?  Bullshit?  Words fail to describe it.

The “style” property of DOM element objects refers to an object that 
implements the CSSStyleDeclaration interface, whose properties in turn 
have values that reflect the properties declared in the “style” attribute 
value of the represented element.

This has absolutely nothing to do with any script engine or the programming 
language.  The programming language – an ECMAScript implementation – is just 
the interface language to the language-independent DOM API here.  (Almost 
needless to say that there is no “Javascript engine” either, because there 
is no “Javascript”.)

<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-58190037>


PointedEars, shaking his head
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#17653

Thomas 'PointedEars' Lahn  wrote:
> Scott Sauyet wrote:
>> JeffG  wrote:
>>> [ ... ]
>>> For some reason, the function is unable to return the style.display
>>> value that was set by the CSS file [ ... ]
>
>> `someElement.style` represents the collection of properties known to
>> the Javascript engine, which is, chiefly, the ones set by that
>> engine.
>
> What can one say to such a mindbogglingly large amount of misinformation in
> just one sentence?  Nonsense?  Bullshit?  Words fail to describe it.

You're right.  How could I have been so careless?  An updated version
that carefully takes account of the worthwhile parts of your critique
is below.

> The “style” property of DOM element objects refers to an object that
> implements the CSSStyleDeclaration interface, whose properties in turn
> have values that reflect the properties declared in the “style” attribute
> value of the represented element.

Yes it's an object, a collection of named properties.  And I didn't
mention that the properties had names.  How careless of me.

> This has absolutely nothing to do with any script engine or the programming
> language.  The programming language – an ECMAScript implementation – is just
> the interface language to the language-independent DOM API here.  (Almost
> needless to say that there is no “Javascript engine” either, because there
> is no “Javascript”.)

I'm sorry, you seem to be in the wrong newsgroup.  Hereabouts we
discuss Javascript.  If you're looking for comp.lang.ecmascript-
implementations, it's next door.  And there's plenty of seating.

The language-independent DOM API does not specify `someElement.style`,
nor the collection of properties used to access and mutate it.  That's
part of Javascript.  So as far as I can tell, the DOM API is entirely
irrelevant.

So let me amend my original statement:

| `someElement.style` represents the collection of named properties
known
| to the Javascript engine, which are the ones set by that engine,
unless
| you're living in the dark ages and still include <STYLE> tags on
your
| pages.

Is that better?

  -- Scott

[toc] | [prev] | [next] | [standalone]

#17654

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn  wrote:
>> Scott Sauyet wrote:
>>> JeffG  wrote:
>>>> [ ... ]
>>>> For some reason, the function is unable to return the style.display
>>>> value that was set by the CSS file [ ... ]
>>> `someElement.style` represents the collection of properties known to
>>> the Javascript engine, which is, chiefly, the ones set by that
>>> engine.
>> What can one say to such a mindbogglingly large amount of misinformation
>> in just one sentence?  Nonsense?  Bullshit?  Words fail to describe it.
> 
> You're right.  How could I have been so careless?  An updated version
> that carefully takes account of the worthwhile parts of your critique
> is below.
> 
>> The “style” property of DOM element objects refers to an object that
>> implements the CSSStyleDeclaration interface, whose properties in turn
>> have values that reflect the properties declared in the “style” attribute
>> value of the represented element.
> 
> Yes it's an object, a collection of named properties.  And I didn't
> mention that the properties had names.  How careless of me.

Don't be silly.  The term “collection” always had a very distinct and 
special meaning with regard to browser APIs, pertaining to their interfaces 
(e.g., HTMLCollection and HTMLOptionsCollection).  The host object referred 
to by the ”style” property is _not_ a collection.

<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506>
<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#HTMLOptionsCollection>
<http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-ElementCSSInlineStyle>
<http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration>

<http://dev.w3.org/html5/spec/single-page.html#collections>
<http://dev.w3.org/html5/spec/single-page.html#the-style-attribute>
 
>> This has absolutely nothing to do with any script engine or the
>> programming language.  The programming language – an ECMAScript
>> implementation – is just the interface language to the
>> language-independent DOM API here.  (Almost needless to say that there is
>> no “Javascript engine” either, because there is no “Javascript”.)
> 
> I'm sorry, you seem to be in the wrong newsgroup.  Hereabouts we
> discuss Javascript.  If you're looking for comp.lang.ecmascript-
> implementations, it's next door.  And there's plenty of seating.

Like a true ignorant, you are attacking what you do not understand.
 
> The language-independent DOM API does not specify `someElement.style`,
> nor the collection of properties used to access and mutate it.  That's
> part of Javascript.  So as far as I can tell, the DOM API is entirely
> irrelevant.

No, it is very relevant.  A DOM API is _not_ a part of the here-relevant 
programming language (that has changed from JavaScript 1.3 to 1.4 because of 
NES, but was never different with other ECMAScript implementations).

A script engine (such as SpiderMonkey, the script engine of Netscape/Mozilla 
JavaScript) could not care less about properties that DOM objects provide 
until those objects are accessed by program code.  The W3C DOM API has an 
ECMAScript language binding specified that allows its implementations to be 
used with ECMAScript implementations, for example JavaScript.  And a 
browser's *layout engine* implements the interfaces of that Specification
as (ECMAScript) *host* objects according to the language binding of the 
respective interfaces.

<http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html>
<http://www.w3.org/TR/DOM-Level-3-Core/ecma-script-binding.html>
<http://www.w3.org/TR/DOM-Level-2-Style/ecma-script-binding.html>
aso.
 
> So let me amend my original statement:

[Fixed Google-borken quotation]

> | `someElement.style` represents the collection of named properties
> | known to the Javascript engine, which are the ones set by that engine,
> | unless you're living in the dark ages and still include <STYLE> tags on
> | your pages.
> 
> Is that better?

No, you still have not the least bit of a shadow a clue what you are talking 
about; sadly, that includes HTML (“<STYLE> tag”?).  And if your postings in 
this thread are examples of what the new FAQ is going to be, you should sure 
hope that you find many knowledgable people to help correct your many 
wannabe misconceptions, unless you want to have its readers unlearn even 
more than if they had read one of the many bad books out there in the first 
place.


PointedEars
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#17657

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn  wrote:
>>> Scott Sauyet wrote:
>>>> JeffG  wrote:
>>>>> [ ... ]
>>>>> For some reason, the function is unable to return the style.display
>>>>> value that was set by the CSS file [ ... ]
>>>> `someElement.style` represents the collection of properties known to
>>>> the Javascript engine, which is, chiefly, the ones set by that
>>>> engine.
>>> What can one say to such a mindbogglingly large amount of misinformation
>>> in just one sentence?  Nonsense?  Bullshit?  Words fail to describe it.
>
>> You're right.  How could I have been so careless?  An updated version
>> that carefully takes account of the worthwhile parts of your critique
>> is below.
>
>>> The “style” property of DOM element objects refers to an object that
>>> implements the CSSStyleDeclaration interface, whose properties in turn
>>> have values that reflect the properties declared in the “style” attribute
>>> value of the represented element.
>
>> Yes it's an object, a collection of named properties.  And I didn't
>> mention that the properties had names.  How careless of me.
>
> Don't be silly.  The term “collection” always had a very distinct and
> special meaning with regard to browser APIs, pertaining to their interfaces
> (e.g., HTMLCollection and HTMLOptionsCollection).  The host object referred
> to by the ”style” property is _not_ a collection.
>
> <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-75708506>
> <http://www.w3.org/TR/DOM-Level-2-HTML/html.html#HTMLOptionsCollection>
> <http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-ElementCSSInlineS...>
> <http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSSStyleDeclaration>
>
> <http://dev.w3.org/html5/spec/single-page.html#collections>
> <http://dev.w3.org/html5/spec/single-page.html#the-style-attribute>

Wow, you know how to search specifications too?  How about
dictionaries?

    <http://dictionary.reference.com/browse/collection>
    <http://en.wiktionary.org/wiki/collection>
    <http://www.merriam-webster.com/dictionary/collection>

I do understand the DOM APIs.  I'm arguing that they are not relevant
to the user's question.  Did you really not understand that?  Or are
you being intentionally obnoxious?

>>> This has absolutely nothing to do with any script engine or the
>>> programming language.  The programming language – an ECMAScript
>>> implementation – is just the interface language to the
>>> language-independent DOM API here.  (Almost needless to say that there is
>>> no “Javascript engine” either, because there is no “Javascript”.)
>
>> I'm sorry, you seem to be in the wrong newsgroup.  Hereabouts we
>> discuss Javascript.  If you're looking for comp.lang.ecmascript-
>> implementations, it's next door.  And there's plenty of seating.
>
> Like a true ignorant, you are attacking what you do not understand.

No, as many others have done, I'm mocking a stance that you make here
_ad nauseum_.  I disagree with your stance, but rarely have made that
disagreement public.  When it was directed at my post, I responded.
As I often do, I tried to do so with some humor, but also with a
little bite.  I think mine was not as effective as another posted
recently pointing out that there are no sunrises either.

Seriously, though, if you think the name is so bad, have you organized
a CFV to create a different group, one which would focus correctly on
the specification?  If not, why not?  As it is, you sound somewhat
like a person constantly haranguing sci.math with some version of
"There is no mathematics; there is only algebra, topology, and number
theory, and so forth."  Regardless of the philosophical truth or
falsity of the claim, the constant repetition would be just an
irritant to working mathematicians.

I am a working Javascript programmer.  I code eight or nine hours per
day, almost all of that in Javascript.  I certainly believe there is
such a thing as Javascript.  I work with it every day.  I do
understand that there are distinct implementations that adhere to
varying degrees to the ECMAScript specification.  But I am not an
ECMAScript programmer.  I am a Javascript programmer.  Your repeated
incorrect assertions that the subject matter of my job doesn't exist
is a minor irritant.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#17658

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn  wrote:
>>>> Scott Sauyet wrote:
>>>>> JeffG  wrote:
>>>>>> [ ... ]
>>>>>> For some reason, the function is unable to return the style.display
>>>>>> value that was set by the CSS file [ ... ]
>>>>> `someElement.style` represents the collection of properties known to
>>>>> the Javascript engine, which is, chiefly, the ones set by that
>>>>> engine.
> […]
> I do understand the DOM APIs.

No, evidently you do not.

> I'm arguing that they are not relevant to the user's question.

Which is wrong.  The “style” property of element *host* objects is there 
*because of* the DOM APIs, not because of a script engine.

> Did you really not understand that?

I fully understand that and why you are wrong.

> Or are you being intentionally obnoxious?

I am trying to tell you that and why you are wrong, but you are not 
listening.

> Seriously, though, if you think the name is so bad, have you organized
> a CFV to create a different group, one which would focus correctly on
> the specification? If not, why not?

There is no need for a different newsgroup.  This newsgroup has evolved into 
what you do not want to see: a newsgroup for discussions about ECMAScript 
implementations and their applications, whereas the latter naturally 
includes the DOM API.  The newsgroup does not need to be renamed, because 
JavaScript still is an ECMAScript implementation (although its tagline 
should be updated).  And it should not be renamed because then – given 
especially misconceptions such as you have them – it would be harder to find 
for the interested, and all people who have already subscribed or are 
peering the newsgroup would have to change their setups.

> I am a working Javascript programmer.

No, you are not.

> I code eight or nine hours per day, almost all of that in Javascript.

No, you don't.

> I certainly believe there is such a thing as Javascript.

Then you are a fool.

> I work with it every day.

An incompetent fool.  I pity your customers already.

> I do understand that there are distinct implementations that adhere to
> varying degrees to the ECMAScript specification.

Evidently you have not understood anything of what I told you.

> But I am not an ECMAScript programmer.

Yes, at least in a way you are (you are using ECMAScript implementations; if 
you script SVG you are using ECMAScript for real), but you refuse to accept 
it.

> I am a Javascript programmer.

See what I mean?

> Your repeated incorrect assertions that the subject matter of my job
> doesn't exist is a minor irritant.

I am working as a Web application developer.  That includes, but is not 
limited to, using ECMAScript implementations such as Mozilla JavaScript, 
Microsoft JScript, Google V8 JavaScript, Apple JavaScriptCore, Opera 
ECMAScript, and KDE JavaScript, to manipulate web browsers and web documents 
through implementations of DOM APIs.


PointedEars
-- 
var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
)  // Plone, register_function.js:16

[toc] | [prev] | [next] | [standalone]

#17661

On 2012-12-10 16:04, Thomas 'PointedEars' Lahn wrote:
..
>> Thomas 'PointedEars' Lahn  wrote:
>>> The “style” property of DOM element objects refers to an object that
>>> implements the CSSStyleDeclaration interface, whose properties in turn
>>> have values that reflect the properties declared in the “style” attribute
>>> value of the represented element.

Those properties are part of the CSS2Properties interface, not the
CSSStyleDeclaration interface.

>>> there is no “Javascript”.

Repetitive like a prayer mill...
Or maybe a different type of mill: http://i.imgur.com/5UhdL.png

> And if your postings in 
> this thread are examples of what the new FAQ is going to be, you should sure 
> hope that you find many knowledgable people to help correct your many 
> wannabe misconceptions, unless you want [rant snipped]

You've expressed an interest in becoming an FAQ maintainer. Now there's
an actual effort to make the current FAQ editable and maintainable, but
I haven't seen any response from you about it yet. Are you going to
participate in this, or would you rather continue looking for week-old
posts to criticize?

- stefan

[toc] | [prev] | [next] | [standalone]

#17662

On 11/12/2012 8:45 AM, Stefan Weiss wrote:
> On 2012-12-10 16:04, Thomas 'PointedEars' Lahn wrote:

...

> You've expressed an interest in becoming an FAQ maintainer. Now there's
> an actual effort to make the current FAQ editable and maintainable, but
> I haven't seen any response from you about it yet. Are you going to
> participate in this, or would you rather continue looking for week-old
> posts to criticize?

You (and I) have no idea of his present commitments, health... so ease 
up on the denigration.

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#17663

Stefan Weiss wrote:

> On 2012-12-10 16:04, Thomas 'PointedEars' Lahn wrote:
>>> Thomas 'PointedEars' Lahn  wrote:
>>>> The “style” property of DOM element objects refers to an object that
>>>> implements the CSSStyleDeclaration interface, whose properties in turn
>>>> have values that reflect the properties declared in the “style”
>>>> attribute value of the represented element.
> 
> Those properties are part of the CSS2Properties interface, not the
> CSSStyleDeclaration interface.

Correct.  I was describing the referred object, not the interface (the comma 
was intended to make that clear).  Interfaces have attributes; objects have 
properties.  It should be noted that …

,-<http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSS2Properties>
| 
| Getting an attribute of this interface is equivalent to calling the
| getPropertyValue method of the CSSStyleDeclaration interface. Setting an
| attribute of this interface is equivalent to calling the setProperty
| method of the CSSStyleDeclaration interface.

The CSS2Properties interface is referred to from the description of the 
CSSStyleDeclaration interface, so the latter is a good start for reading.  
That also shows why the property name is “style”: the ElementCSSInlineStyle 
interface has a single attribute named “style” of type 
“CSSStyleDeclaration”, which element objects implement.


HTH

PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)	

[toc] | [prev] | [next] | [standalone]

#17655

> Scott Sauyet  wrote:

> So let me amend my original statement:
>
>| `someElement.style` represents the collection of named properties
>| known  to the Javascript engine, which are the ones set by that
>| engine, unless you're living in the dark ages and still include
>| <STYLE> tags on your pages.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^
Correction:

"and still include style attribute on you elements"

Sorry, posting in a hurry.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#17656

Scott Sauyet wrote:

> Scott Sauyet  wrote:
>> So let me amend my original statement:
>>| `someElement.style` represents the collection of named properties
>>| known  to the Javascript engine, which are the ones set by that
>>| engine, unless you're living in the dark ages and still include
>>| <STYLE> tags on your pages.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^
> Correction:
> 
> "and still include style attribute on you elements"

Still wrong.


PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#17367

Am 27.11.2012 17:08, schrieb JeffG:
> I am creating a table of contents with nested UL lists. Many of the LI tags contain A tags and the UL of a lower-level list. The A tags call a function meant to show toggle display of the lower level lists.
> The link passes the "this" keyword to the function, which gets the parent node and then finds the sibling UL.
> For some reason, the function is unable to return the style.display value that was set by the CSS file (Loaded before the javascript). So the first time I run the function by clicking the link, my "if" test always goes to the else statement.
> What am I doing wrong?
> Here is the function:
> function TocOpenClose(Anc) {
> 	var parenLI;
> 	var NextUL;
> 	parenLI = Anc.parentNode;
> 	NextUL = parenLI.getElementsByTagName("ul")[0];
>
> 	if (NextUL.style.display=="none")
> 	{
> 		NextUL.style.display = "block";
> 	}
> 	else
> 	{
> 		NextUL.style.display = "none";
> 	}
> }
>

The problem is the style property _only_ reflects inline style 
information (<ul style="...">).

One approach could be to use special class names for the elements, you 
can check for existence and add/remove them relatively easily.

-- 
Jake Jarvis

[toc] | [prev] | [next] | [standalone]

#17368

Jake Jarvis wrote:

> Am 27.11.2012 17:08, schrieb JeffG:
>> I am creating a table of contents with nested UL lists. Many of the LI
>> tags contain A tags and the UL of a lower-level list. The A tags call a
>> function meant to show toggle display of the lower level lists. The link
>> passes the "this" keyword to the function, which gets the parent node and
>> then finds the sibling UL. For some reason, the function is unable to
>> return the style.display value that was set by the CSS file (Loaded
>> before the javascript). So the first time I run the function by clicking
>> the link, my "if" test always goes to the else statement. What am I doing
>> wrong? Here is the function: function TocOpenClose(Anc) { var parenLI;
>> var NextUL; parenLI = Anc.parentNode; NextUL =
>> parenLI.getElementsByTagName("ul")[0];
>>
>> if (NextUL.style.display=="none")
>> {
>> NextUL.style.display = "block";
>> }
>> else
>> {
>> NextUL.style.display = "none";
>> }
>> }
>>
> 
> The problem is the style property _only_ reflects inline style
> information (<ul style="...">).
> 
> One approach could be to use special class names for the elements, you
> can check for existence and add/remove them relatively easily.

In this case it is better to not hide elements by default, to hide them with 
client-side scripting when the document has been loaded, and to assign "" 
instead of "block".  The Web site should work without sufficient client-side 
script support as well.  It is prudent to wrap the list into a user-defined 
widget object that eases modification of the list as an outline.
 

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> (404-comp.)

[toc] | [prev] | [next] | [standalone]

#17369

This is incredibly helpful. I will make use of all your suggestions in various aspects of my project - not just this function.

[toc] | [prev] | [next] | [standalone]

#17370

In article <4620a8a4-7848-4ca7-941e-c826259acbac@googlegroups.com>,
 JeffG <jeffgutsell@fuse.net> wrote:

> This is incredibly helpful. I will make use of all your suggestions in 
> various aspects of my project - not just this function.

I had to deduce empirically that elementPtr.style gave incomplete 
information, however I've yet to see any reason for that, good or bad. 
Getting the required style info can be done, but seems to involve some 
steps. For example:

  compPtr  = document.getElementById (comp);
  stylePtr = document.defaultView.getComputedStyle (compPtr, null);
  height   = parseInt (stylePtr.getPropertyValue ("height"));

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#17372

Tim Streater wrote:

> JeffG <jeffgutsell@fuse.net> wrote:
>> This is incredibly helpful. I will make use of all your suggestions in
>> various aspects of my project - not just this function.
> 
> I had to deduce empirically that elementPtr.style gave incomplete
> information, however I've yet to see any reason for that, good or bad.
> Getting the required style info can be done, but seems to involve some
> steps. For example:
> 
>   compPtr  = document.getElementById (comp);
>   stylePtr = document.defaultView.getComputedStyle (compPtr, null);
>   height   = parseInt (stylePtr.getPropertyValue ("height"));
                                                             ^
Wrong, see <news:1788183.LAg6v8g3if@PointedEars.de>.  A fallback for 
MSHTML < 9 is also missing.  It is usually better not to rely on the 
computed style; certainly it is not necessary here.

It is also considered good style to let argument lists – by contrast to 
operands – be _not_ delimited by whitespace from the method property access:

  var height = parseInt(stylePtr.getPropertyValue("height"), 10);


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@news.demon.co.uk>

[toc] | [prev] | [next] | [standalone]

#17373

In article <3709927.HS29Ki5Fzn@PointedEars.de>,
 Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:

> Tim Streater wrote:
> 
> > JeffG <jeffgutsell@fuse.net> wrote:
> >> This is incredibly helpful. I will make use of all your suggestions in
> >> various aspects of my project - not just this function.
> > 
> > I had to deduce empirically that elementPtr.style gave incomplete
> > information, however I've yet to see any reason for that, good or bad.
> > Getting the required style info can be done, but seems to involve some
> > steps. For example:
> > 
> >   compPtr  = document.getElementById (comp);
> >   stylePtr = document.defaultView.getComputedStyle (compPtr, null);
> >   height   = parseInt (stylePtr.getPropertyValue ("height"));
>                                                              ^
> Wrong, see <news:1788183.LAg6v8g3if@PointedEars.de>.  A fallback for 
> MSHTML < 9 is also missing.

I have zero interest in *any* version of IE.

> It is usually better not to rely on the 
> computed style; certainly it is not necessary here.

In the instance from which I drew the code it was not merely necessary, 
but vital.

> It is also considered good style to let argument lists – by contrast to 
> operands – be _not_ delimited by whitespace from the method property access:
> 
>   var height = parseInt(stylePtr.getPropertyValue("height"), 10);

Your views on what constitutes good style are a matter of complete 
indifference to me.

As usual you jump in with both feet and make a fool of yourself. Now go 
away - again.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#17374

Tim Streater wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>> Tim Streater wrote:
>> > JeffG <jeffgutsell@fuse.net> wrote:
>> >> This is incredibly helpful. I will make use of all your suggestions in
>> >> various aspects of my project - not just this function.
>> > 
>> > I had to deduce empirically that elementPtr.style gave incomplete
>> > information, however I've yet to see any reason for that, good or bad.
>> > Getting the required style info can be done, but seems to involve some
>> > steps. For example:
>> > 
>> >   compPtr  = document.getElementById (comp);
>> >   stylePtr = document.defaultView.getComputedStyle (compPtr, null);
>> >   height   = parseInt (stylePtr.getPropertyValue ("height"));
>>                                                              ^
>> Wrong, see <news:1788183.LAg6v8g3if@PointedEars.de>.  A fallback for
>> MSHTML < 9 is also missing.
> 
> I have zero interest in *any* version of IE.

IOW, you are an incompetent fool.

>> It is usually better not to rely on the
>> computed style; certainly it is not necessary here.
> 
> In the instance from which I drew the code it was not merely necessary,
> but vital.

That is what "usually" means.  This one is not one rare of the occasions 
where using the computed style is either necessary or vital, because the 
approach that leads to the necessity here is wrong.
 
>> It is also considered good style to let argument lists – by contrast to
>> operands – be _not_ delimited by whitespace from the method property
>> access:
>> 
>>   var height = parseInt(stylePtr.getPropertyValue("height"), 10);
> 
> Your views on what constitutes good style are a matter of complete
> indifference to me.

Those are not merely my views.

> As usual you jump in with both feet and make a fool of yourself. Now go
> away - again.

You are talking to the mirror again.


PointedEars
-- 
Sometimes, what you learn is wrong. If those wrong ideas are close to the 
root of the knowledge tree you build on a particular subject, pruning the 
bad branches can sometimes cause the whole tree to collapse.
  -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web