No properties?

[createErrorMsg]

Hey all,

Everytime the page in question runs this script on onload...

function setFont() {
newfont = readCookie('font');
document.getElementsByTagName('body')[0].style.fontSize = newfont;
}

it sends an error (in FF's javascript console)...

document.getElementsByTagName('body')[0] has no properties (line 3).

BUT, the script still works (I know because the font value returned by readCookie() is applied to the page).

Part of me is tempted to let it go, since things are working, but another part of me is concerned about the error message on every page change (don't want observant users to get the impression that I don't know what I'm doing - haha).

Anybody know of a way to prevent the error message? Clearly it's coming up because, until the script applies a value to the body tag's style attribute, it has none. I tried an if statement to check for a value before adding the value, but this did nothing.

Any thoughts? Thanks in advance for any responses.

[Bernard Marx]

I don't know the cause of that error there (hmm. I think that one was one of mine).
It works in my browsers, so, as long as the function is being called by some onload event handler, as you say, then perhaps it's some FF bug (or maybe it wants you to set style props on the documentElement).

To hide errors in the browser, use one of these assignments:

// #1

window.onerror = function(){return true}
// or #2
window.onerror = function(msg,url,line)
{
 alert("Error\nmsg: "+msg+"\nurl: "+url+"\nline: "+line)
 return true
}
null.createAnError = now

#2 shows you how to createErrorMsg.

[createErrorMsg]

#2 shows you how to createErrorMsg

lol. That function must be running somewhere in my brain. ;)

Since the thing is working, it's only leading others to believe that it might not be that has me concerned. Hiding the errors sounds like a good solution.

Thanks again.

[Bernard Marx]

It still bugs me that there is an error at all. Especially considering the script works.
Is it only in FF that you get an error?

what happens if you replace the offending line with this?:

alert("doc.get:\n"+document.getElementsByTagName)
alert("doc.get('b'):\n"+document.getElementsByTagName('body'))
alert("doc.get('b')[0]:\n"+document.getElementsByTagName('body')[0])
alert("doc.get('b')[0].style:\n"+document.getElementsByTagName('body')[0].style)

[Rambo Tribble]

Perhaps it is an error deriving from the execution scope. getElementsByTagName() returns an array of the elements that match the specified tag name, which are descendants from the current element from which the method is launched. If the browser interprets the body as the current element, it has no descendant body element.

If you are currently using the body onload event to trigger the function, you might try using the window onload and assign it as an event handler:

window.onload=function(){
//your code
}

[Bernard Marx]

That's an interesting angle (although document should mean either the HTML element, or the whole doc - depending on browser. I get a bit confused here, which leads me to ask you..)

What's the current status of document.body as a reference?
Is it safe to use, or does it not work somewhere? It doesn't look W3C-strict, but then element.style is deprecated, and everyone still uses it.

[Rambo Tribble]

I don't know of any problem with document.body, but then I am surprised to hear that element.style is deprecated. Frankly, I'm not aware of any other way to address an element's style properties with a script.

I wouldn't think it is the syntax of the document.~ that would be the source of the problem, but rather the context; if the getElementsByTagName() is being called from the body element, then it would be the body.document.body that would be the target.

It might be instructive to find out what the interpreters are returning as the value of "this" in the context of the method call.

[Bernard Marx]

I don't think it's the context, since, whatever the context of

setFont

,

getEls

is being called from

document

. Anyway, yadda-yadda, I don't understand generally.

Talking about things I don't understand...

me >> "but then element.style is deprecated, and everyone still uses it"

You're right. I should have said

element.style.propertyName

.

Have a look at this earlier thread [webmasterworld.com], where I said: "if some bright spark somewhere is thinking of deprecating the simpler approach" (#) - meaning that I couldn't see any reason not to use it.

It turns out I was wrong. I found a W3C document that says that this form of set/getting style properties is not recommended, and that the getPropertyValue method should be used (as DCrombie was doing). Now I've lost the URL. To me, that place is an incomprehensible maze. Any tips?

[Rambo Tribble]

Ah, yes, the get 'n' set methods of the CSSStyleDeclaration object. I knew I'd get myself in trouble with that ill-advised line about ". . .not aware. . ." Or, as my Great Aunt Foramena used to say, "If you use hasty words, choose tasty words, for odds are good you'll have to eat them."

That said, I was of the impression that the 400-kilo gorilla of the Internet, IE Win, didn't do CSSStyleDeclaration, so that style.etc~ was really the only cross-browser approach.

It is the part about getElementsByTagName() starting from the "current" element, but not including it that makes me suspect that FF is interpreting the body as the calling element of its execution context. The error that the JavaScript Console is providing is usually seen (in my, admittedly, limited experience) when an object doesn't exist. Though, I'm not seeing the error on Moz 1.5, but FF, like Great Aunt Foramena, tends to a stricter interpretation.

[edited by: Rambo_Tribble at 3:13 pm (utc) on Aug. 23, 2004]

[Bernard Marx]

I certainly dig where you're coming from. The next issue, of course, is that createErrorMsg says that the script actually works anyway.

About that other thing, you don't happen to have a collection of links handy to useful W3C spec documentation? I can find the "recommendations", but I can't find the document that talked to you a little more - the one that said "Hmmm, best not do that".

[Rambo Tribble]

I used Goodman's "Dynamic HTML" as my reference.

The part where the script works despite the error is, I agree, the most perplexing aspect of the issue. It suggests the console returns errors that the interpreter papers over in rendition; there is a substantial body of evidence supporting that as the case, in fact.