I don't beleive so. Because offsetHeight does not -always- equal
scrollHeight.
scrollHeight is the true content width. offsetHeight is the width of the
visble portion of content. When the content height is such that it
doesn't overflow (require scroll handling) offsetHeight and scrollHeight
are the same or less. On IE/Mac though, scrollHeight is NaN until you
'access' the offsetHeight property.
So what should happen? I think this...
(Some ansi art to explain what i'm thinking better)
a.
+------------+
| content | c.
+-----------------+
| |
| Div with |
| overflowing |
| content |
| |
| |
+-----------------+
| content | d.
+------------+
b.
In the above diagram, scrollHeight is from point A to point B.
offsetHeight is from point C to point D. Thus, content height is
scrollHeight and not offsetHeight.
c.
+-----------------+
| +------------+a |
| | content | |
| | | |
| | Div | |
| | without | |
| | overflow | |
| | | |
| | content | |
| +------------+b |
+-----------------+
d.
In the above diagram, offsetHeight is from point c to point d (still).
But the real content height is less than that, it's A to B, which is
scrollHeight (or should be). This is where there is some problem with
IE-Mac and DynAPI2. In my label test, if i ask for scrollHeight from
something that looks like the above diagram, i get NaN. if i ask for
offsetHeight i get C to D (correctly), and then magicall, scrollHeight
has a value (though it seems to always equal offsetHeight until your
content breaks past offsetHeight and scrolls).
Now, all dynlayers with a height, get a clip rect setup. So that plays
into all this as well.
Ok after writing all the above, and doing more test, i'm at the "I DONT
KNOW" stage again. The second hack I mentioned is what I'm going with,
but i'm still narrowing down, and removing variables from some DynAPI
code that will point out specifically what breaks and where.
I'd appreciate anyone else doing test with labels.js and IE5-Mac (they
work perfect on NS 4.7 mac). I need to look at all this again tmrw with
fresh eyes.
-frank
-----Original Message-----
From: Michael Pemberton [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 13, 2001 1:31 AM
To: [EMAIL PROTECTED]
Subject: Re: [Dynapi-Dev] Mac bug & fix....
does this mean that the getContentWidth / getContentHeight methods can
now
read:
-------------------------------------------------------
DynLayer.prototype.getContentWidth=function() {
if (this.elm==null) return 0;
else if (is.ns4) return this.doc.width;
else return parseInt(this.elm.offsetWidth);
};
DynLayer.prototype.getContentHeight=function() {
if (this.elm==null) return 0;
else if (is.ns4) return this.doc.height;
else return parseInt(this.elm.offsetHeight);
};
-------------------------------------------------------
OffsetHeight is already used as the NS6 option.
"Frank T. O'Connor" wrote:
> In this article:
> http://www.geocrawler.com/archives/3/7119/2000/11/0/4715441/
>
> (fron last year)
> Two people we're discussing a bug with getContentHeight in IE5 for the
> mac.
>
> Well, a partial work around was suggested, and then according to my
> search nothing else was ever discussed. I just ran into this bug using
> the label.js class with IE 5 Mac. Six hours of my life are forever
gone
> and wasted using DynAPI.console.write() and a Mac (bleh) tracing this
> very same bug down in my code. I really hope someone takes this patch
> and implements it so that noone else is left tracing the same bug for
> the bettter part of a day.
>
> Details:
> this.elm.scrollHeight in IE 5 Mac returns NaN if the content doesn't
> overflow the div. this.elm.offsetHeight is the same height as
> non-overflowing scrollHeight (see:
> http://msdn.microsoft.com/workshop/author/om/measuring.asp for pretty
> pictures of what all these CSS properties mean) and thus a vaiable
> workaround is:
>
> "else if (is.ie) return parseInt(isNaN(this.elm.scrollHeight)?
> this.elm.offsetHeight : this.elm.scrollHeight));"
> in DynLayer.prototype.getContentHeight
>
> Upon further testing, i found a somewhat intresting bug that leaves us
a
> second choice to patching this. If you access the elm.offsetHeight
> property BEFORE access elm.scrollHeight then scrollHeight has the
proper
> value (scrollHeight = offsetHeight). This is vaguely reminiscent of an
> old NS bug, where values of CSS properties would not fill in until
after
> you access them or other properties in a certain order. Anyhow,
another
> solution, possibly better (???) than the previous is this:
>
> else if (is.ie){
> this.elm.offsetHeight //Mac hack, forces scrollHeight to fill
> due to IE 5 mac bug
> return parseInt(this.elm.scrollHeight);
> }
>
> Comments? suggestion?
>
> BTW, anyone know of a JScript dbugger on the Mac that hooks up to IE
5?
> it's insane tracking down bugs w/o the ability to see a call stack, or
> trace.
>
> -frank
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
--
Michael Pemberton
[EMAIL PROTECTED]
ICQ: 12107010
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
