By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,353 Members | 1,237 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,353 IT Pros & Developers. It's quick & easy.

CSIEStyl error

P: n/a
This function of [inherited] javascript is producing errors

function CSIEStyl(s) { return document.all.tags("div")[s].style; }

On inspection document.all doesn't have a 'tags' hanging off it.
The function [CSIEStyl] which seems to be prolific [over
5000 hits on Google.

The context where it's causing an error is this:

CSIEStyl(s).visibility=(v==0)?"hidden":"visible";

Where s is mossroster

The only place I can find that text in the page is here:

<csaction name="61c7ee54" class="ShowHide" type="onevent" val0="mossroster"
val1="1"></csaction>
<csaction name="805c60" class="ShowHide" type="onevent" val0="mossroster"
val1="1"></csaction>

and here

CSAct[/CMP/ '61c7ee54'] = new Array(CSShowHide,/CMP/ 'mossroster',1);
CSAct[/CMP/ '805c60'] = new Array(CSShowHide,/CMP/ 'mossroster',1);

However, I have no idea what these lines refer to. Esp. the use of CMP??

Any help greatly appreciated!
--
==============
Not a pedant
==============

Mar 6 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
pemo wrote:
This function of [inherited] javascript is producing errors

function CSIEStyl(s) { return document.all.tags("div")[s].style; } ^^ On inspection document.all doesn't have a 'tags' hanging off it.
The name is program here. The above is IE-proprietary. document.all is now
supported by other UAs as well, however, its properties are not equally
supported. Have a preference for standards compliant DOM access instead:

function isMethodType(s)
{
return (s == "function" || s == "object");
}

function CSStyl(s)
{
var coll;

if (isMethodType(typeof document.getElementsByTagName)
&& document.getElementsByTagName)
{
coll = document.getElementsByTagName("div");
}

// required for IE < 5
else if (typeof document.all != "undefined"
&& isMethodType(document.all.tags)
&& document.all.tags)
{
coll = document.all.tags("div");
}

if (coll && coll[s])
{
return coll[s].style;
}

return null;
}
The function [CSIEStyl] which seems to be prolific [over
5000 hits on Google.
It is a sad truth that bad code is often wider distributed than good one.
IE-based UAs compared to Gecko-based UAs, for example.
The context where it's causing an error is this:

CSIEStyl(s).visibility=(v==0)?"hidden":"visible";
What do you expect? The referencing itself is error-prone.
It should be at least

var o;
if ((o = CSIEStyl(s)))
{
o.visibility = v ? "visible": "hidden";
}

Note that if we assume `x' is numeric or boolean,

(x == 0) ? true_value : false_value
(x == false) ? true_value : false_value

is (due to implicit type conversion) semantically equal to

x ? false_value : true_value

(0 == false).
Where s is mossroster

The only place I can find that text in the page is here:

<csaction name="61c7ee54" class="ShowHide" type="onevent" val0="mossroster" val1="1"></csaction>
<csaction name="805c60" class="ShowHide" type="onevent" val0="mossroster"
val1="1"></csaction>
There is no such element as `csaction' in HTML or XHTML. Apparently this
is generator code. Google tells that it is used by Adobe GoLive
(CyberStudio; hence the "cs") for "JavaScript Actions". What Adobe calls
that "proprietary GoLive HTML code elements" that "can be stripped during
FTP upload or export of the page.", I call it not Valid HTML. Probably
if the option is not used to strip those elements during FTP upload (which
would most certainly have to be performed with GoLive), or when the "page"
is "exported", , one will end up with that invalid markup.

<URL:http://www.adobe.com/products/golive/pdfs/gl_whtpr_js.pdf>
and here

CSAct[/CMP/ '61c7ee54'] = new Array(CSShowHide,/CMP/ 'mossroster',1);
CSAct[/CMP/ '805c60'] = new Array(CSShowHide,/CMP/ 'mossroster',1);

However, I have no idea what these lines refer to. Esp. the use of CMP??
This is syntactically incorrect ECMAScript code:

| Error: missing ] in index expression
| Source file: javascript:CSAct[/CMP/ '61c7ee54'] = new
| Array(CSShowHide,/CMP/ 'mossroster',1);
| Line: 1, Column: 12
| Source code:
| CSAct[/CMP/ '61c7ee54'] = new Array(CSShowHide,/CMP/ 'mossroster',1);
| --------------^

Most certainly it is generator code as well. Watch for what the client
gets instead (View Source).
-- ^ ==============
Not a pedant
==============


But someone who is not able to delimit his signature properly, due to his
flawed newsreader. <URL:http://insideoe.com/>
PointedEars
Mar 6 '06 #2

P: n/a
Thomas 'PointedEars' Lahn said the following on 3/6/2006 2:32 PM:
pemo wrote:
This function of [inherited] javascript is producing errors

function CSIEStyl(s) { return document.all.tags("div")[s].style; }

^^
On inspection document.all doesn't have a 'tags' hanging off it.


The name is program here. The above is IE-proprietary. document.all is now
supported by other UAs as well, however, its properties are not equally
supported. Have a preference for standards compliant DOM access instead:

function isMethodType(s)
{
return (s == "function" || s == "object");
}

function CSStyl(s)
{
var coll;

if (isMethodType(typeof document.getElementsByTagName)
&& document.getElementsByTagName)


The second half of that if test seems to be superfluous and not needed.

if isMethodType( returns true then document.getElementsByTagName will
always be true.

if isMethodType( returns false then document.getElementsByTagName
existence is irrelevant and the second test is not needed.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Mar 6 '06 #3

P: n/a
VK

Randy Webb wrote:
if (isMethodType(typeof document.getElementsByTagName)
&& document.getElementsByTagName)


The second half of that if test seems to be superfluous and not needed.

if isMethodType( returns true then document.getElementsByTagName will
always be true.

if isMethodType( returns false then document.getElementsByTagName
existence is irrelevant and the second test is not needed.


I missed the beginning of the discussion so I'm not sure what
isMethodType checking for. I hope it takes both "function" and "object"
as valid (true), otherwise it will fail on IE.

In IE all methods of window and document objects reported as 'object',
while in Firefox as 'function'.

Mar 6 '06 #4

P: n/a
VK wrote:
Randy Webb wrote:
> if (isMethodType(typeof document.getElementsByTagName)
> && document.getElementsByTagName)
The second half of that if test seems to be superfluous and not needed.

if isMethodType( returns true then document.getElementsByTagName will
always be true.

if isMethodType( returns false then document.getElementsByTagName
existence is irrelevant and the second test is not needed.


I missed the beginning of the discussion so I'm not sure what
isMethodType checking for.


Google Groups, which you use, shows the complete discussion always,
except postings with "X-No-Archive: Yes" header.
I hope it takes both "function" and "object" as valid (true), [...]


It does. Therefore, the second half is not superfluous, and it is
needed; the property value could be `null' and typeof null == "object".
PointedEars
Mar 6 '06 #5

P: n/a
Randy Webb wrote:
Thomas 'PointedEars' Lahn said the following on 3/6/2006 2:32 PM:
pemo wrote:
This function of [inherited] javascript is producing errors

function CSIEStyl(s) { return document.all.tags("div")[s].style; }


^^
On inspection document.all doesn't have a 'tags' hanging off it.

The name is program here. The above is IE-proprietary. document.all
is now
supported by other UAs as well, however, its properties are not equally
supported. Have a preference for standards compliant DOM access instead:

function isMethodType(s)
{
return (s == "function" || s == "object");
}

function CSStyl(s)
{
var coll;

if (isMethodType(typeof document.getElementsByTagName)
&& document.getElementsByTagName)

The second half of that if test seems to be superfluous and not needed.

if isMethodType( returns true then document.getElementsByTagName will
always be true.

if isMethodType( returns false then document.getElementsByTagName
existence is irrelevant and the second test is not needed.


Not sure where to join the thread here...
Shouldn't the 'typeof' operator be inside isMethodType? Then it can be:

function isMethodType(s)
{
return (null != s && ("function"==typeof s || "object"==typeof s));
}

and called with:

isMethodType(document.getElementsByTagName)
But it seems pretty pointless anyway, isMethodType will return true for
any non-null object. The usefulness of the 'function' test is
completely subverted by the - || object - bit.

Something like isMethodType is only seems relevant in a situation where
you are contributing to shared libraries and you don't know what anyone
else is doing. But a fundamental principle in such situations is
usually to not overwrite native or DOM standard methods - so given the
weakness of the test, what's the point?

Can it be made more robust?
--
Rob
Mar 7 '06 #6

P: n/a
RobG wrote:
Randy Webb wrote:
Thomas 'PointedEars' Lahn said the following on 3/6/2006 2:32 PM:
function isMethodType(s)
{
return (s == "function" || s == "object");
}

function CSStyl(s)
{
var coll;

if (isMethodType(typeof document.getElementsByTagName)
&& document.getElementsByTagName)

The second half of that if test seems to be superfluous and not needed.
Again, this could not be farther from the truth.
if isMethodType( returns true then document.getElementsByTagName will
always be true.

if isMethodType( returns false then document.getElementsByTagName
existence is irrelevant and the second test is not needed.


[...]
Shouldn't the 'typeof' operator be inside isMethodType?


No, it should not.
Then it can be:

function isMethodType(s)
{
return (null != s && ("function"==typeof s || "object"==typeof s));
}

and called with:

isMethodType(document.getElementsByTagName)
And if `document' is not defined, a ReferenceError exception would be
thrown. I have designed that method (included in types.js) as a general
solution for the [[Call]] problem. It is as it is for a reason, you know.
But it seems pretty pointless anyway, isMethodType will return true for
any non-null object.
Works as designed.
The usefulness of the 'function' test is completely subverted by the -
|| object - bit.
It is not.
Something like isMethodType is only seems relevant in a situation where
you are contributing to shared libraries and you don't know what anyone
else is doing.
No, it is relevant for _all_ feature tests. Only for DOM feature tests
you will have to add the additional type-converting test if you want to
support IE.
But a fundamental principle in such situations is usually to not overwrite
native or DOM standard methods - so given the weakness of the test, what's
the point?
The point is that you can determine reliably enough if something can be
called or not.
Can it be made more robust?


There is already isMethod() which can take a string argument and uses eval()
then (which appears to me to be the only way to avoid early evaluation),
but it breaks for null base objects. I have been working on it to handle
that, too, for some time now.
PointedEars
Mar 7 '06 #7

P: n/a
Thomas 'PointedEars' Lahn wrote:
RobG wrote:

Randy Webb wrote: [...]
The second half of that if test seems to be superfluous and not needed.

Again, this could not be farther from the truth.
I'm sure Randy appreciated being told your view again.
[...]Shouldn't the 'typeof' operator be inside isMethodType?


No, it should not.

[...] And if `document' is not defined, a ReferenceError exception would be
thrown. I have designed that method (included in types.js) as a general
solution for the [[Call]] problem. It is as it is for a reason, you know.


Hence why I was asking, you know.

But it seems pretty pointless anyway, isMethodType will return true for
any non-null object.


Works as designed.


Without being given the original design, it is difficult for anyone else
to determine that. And without knowing precisely what it is designed to
do (or not), I am uncertain as to its suitability to various situations.

Hence the questions...

The usefulness of the 'function' test is completely subverted by the -
|| object - bit.


It is not.

Something like isMethodType is only seems relevant in a situation where
you are contributing to shared libraries and you don't know what anyone
else is doing.

No, it is relevant for _all_ feature tests. Only for DOM feature tests
you will have to add the additional type-converting test if you want to
support IE.

But a fundamental principle in such situations is usually to not overwrite
native or DOM standard methods - so given the weakness of the test, what's
the point?

The point is that you can determine reliably enough if something can be
called or not.


'reliably enough' - it is the extent of that reliability that I'd like
to understand clearly. As far as I can tell, all browsers work OK when
dealing with native JavaScript objects when test as follows:

alert( typeof Math.floor ) // shows 'function'
It's when DOM objects are involved that some brosers (e.g. IE) lose the
plot. When allowances are made for these browsers, the tests are weakened.

For example, testing whether typeof document.getElementById returns
'function' seems pretty definitive, but just testing that it's an object
and not null seems a bit soft.

That is not to say that therefore there shouldn't be any testing at all,
only that if the test is weak, can a methodology be employed that
removes the need for such tests and provides the same level of
reliability? Or a better test be devised?

Another aspect is how to determine an appropriate test for the platform
the code is running on. What feature test will tell you if typeof
function is supported for all objects?

For example, in Gecko you can look at a DOM object's constructor:

var x = document.getElementById;
if ( Function == x.constructor ) // returns true

but in IE x.constructor is undefined - which seems to hold true for all
DOM objects in IE. But IE does have a constructor property for native
JavaScript objects, why not with DOM objects and methods? (that's a
rhetorical question... :-) ).

An idea is to use toString(). IE seems to have 'undetectable' support
for toString with DOM objects, you can't call it explicitly:

e.g.

var x = document.getElementById;
alert( x ) // shows function getElementById () {...}
which looks like the result of x.toString(), but

alert( x.toString() ) // shows undefined
alert( typeof x.toString ) // shows undefined
What the...?

Can it be made more robust?

There is already isMethod() which can take a string argument and uses eval()
then (which appears to me to be the only way to avoid early evaluation),
but it breaks for null base objects. I have been working on it to handle
that, too, for some time now.


This one?

function isMethod(o)
{
if (typeof o == "string")
{
o = eval(o);
}

var t;
return ((t = typeof o) == "function" || t == "object" && o);
}
Have you considered two functions, one for native JavaScript objects and
one for DOM? e.g.:

function testMethodNative (o)
{
return ('function' == typeof o);
}

or

function testMethodNative (o)
{
return (Function == o.constructor);
}

Both seem to work fine with native objects like Math.floor, Array.join
and String.split. The following can be used to test DOM objects:
function testMethodDOM (o)
{
if ('function' == typeof document.write){

// Supports typeof function for DOM objects
return ('function' == typeof o);

} else {

// Weaker test for others
return ('object' == typeof o && null != o);
}
}

Or maybe they can be combined, similar to the typical test for
document.getElementById/document.all.

OK, testing document.write is not much better than the olde worlde
assumption that support for document.all means IE, but 'it works'. Is
it any less robust than isMethod or isMethodType? Any UA that doesn't
support document.write is likely not of much use anyway (the use of
document.write is not restricted to visual UAs and should be implemented
by any UA that supports scripting at all).

At least this way users of browsers with decent support for DOM objects
get the added protection of better feature testing, they aren't
penalised by weaker tests that allow for other browsers. This seems to
fit with the principle of graceful degradation.

Maybe a toString test can be included too (allowing for IE's
non-detectability/non-call-ability for toString with DOM objects).

function isMethod(o)
{
return /function /.test(o);
}

Here a better test would be:

return /^function /.test(o);
but IE barfs on that.

--
Rob
Mar 7 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.