why can't I retrieve style properties from DOM?
lcplben
The problem shows up in the one-line display of internal variables
just below the small banner on the page:
http://sellmycalls.com/cgi-bin/chain
In the function scroll( ) at line 52 in the source, I am asking for an
element's style values: e.style.top and e.style.marginTop. I know the
element is there: I would exit the function if not.
Earlier in the code, I can retrieve the innerHTML of the element. What
stupid thing am I doing wrong that keeps me from seeing these style
values?
Thanks!
-- ben
Stefan Weiss
If you didn't set these values with JavaScript, they may not be
accessible as properties of e.style. You'll want to research the offset*
style properties, and other non-standard ways to get the current style
settings of an element (more or less reliably). Google for the
currentStyle property and the getComputedStyle method.
The simplest way to get (more or less) reliable readings is to set these
values yourself with JS, but that may not match your use case (which I
didn't attempt to figure out, because your example is too long :).
cheers,
stefan
Thomas 'PointedEars' Lahn
Contrary to what you state there, your markup is _not_ Valid (you have not
escaped ETAGOs, for example). As for the rest, it is impossible to tell as
you are not telling us in which environment the problem occurs so as for us
to try to reproduce it there.
Your source code indicates that on load the `body' element the element in
question (with ID "to") would be formatted with style.top = style.marginTop
= 0 if `dest' and `src' would type-convert to `true' (you can lose the inner
parentheses, they don't mean anything there). `dest' and `src' are
identifiers of variables being assigned references to the DOM objects
representing elements with ID "to" and "col_hdr", respectively; as these
elements exist within the `body' element on load, it stands to reason that
if the setFixHdr() function is called, given a suitable runtime environment
the element in question would be formatted and the properties should yield
at least the assigned values. (So what Stefan implied should not be an issue.)
However, you include a "compliance patch for microsoft browsers" script for
IE 7 and earlier, which might interfere there.
For a start, assign to `innerHTML' first (or avoid `innerHTML = ""' in favor
of a while-firstChild-removeChild loop), and then assign string values, not
number values to those short-hand style properties.
HTH
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$8300...@news.demon.co.uk>
lcplben
On Oct 2, 4:52 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> lcplben wrote:
> > The problem shows up in the one-line display of internal variables
> > just below the small banner on the page:
http://sellmycalls.com/cgi-bin/chain
>
> > In the function scroll( ) at line 52 in the source, I am asking for an
> > element's style values: e.style.top and e.style.marginTop. I know the
> > element is there: I would exit the function if not.
>
> > Earlier in the code, I can retrieve the innerHTML of the element. What
> > stupid thing am I doing wrong that keeps me from seeing these style
> > values?
>
> Contrary to what you state there, your markup is _not_ Valid
The text of that link is misleading. It's a link to the W3C validator,
not any claim of mine. Thanks for picking that up.
> you have not escaped ETAGOs
What's an ETAGO?
> you are not telling us in which environment the problem occurs so as for us
> to try to reproduce it there.
This problem appears in all of FF 3.5.3 with Firebug 1.4.3, IE7, and
Safari; under WinXP SP3.
> Your source code indicates that on load the `body' element the element in
> question (with ID "to") would be formatted with style.top = style.marginTop
> = 0 if `dest' and `src' would type-convert to `true' (you can lose the inner
> parentheses, they don't mean anything there). `dest' and `src' are
> identifiers of variables being assigned references to the DOM objects
> representing elements with ID "to" and "col_hdr", respectively; as these
> elements exist within the `body' element on load, it stands to reason that
> if the setFixHdr() function is called, given a suitable runtime environment
> the element in question would be formatted and the properties should yield
> at least the assigned values.
Yes, and now that I've I've assigned strings, not numbers, as you
suggest that part works just fine now.
> However, you include a "compliance patch for microsoft browsers" script for
> IE 7 and earlier, which might interfere there.
I thought that was commented out. Well, it's gone now.
> For a start, assign to `innerHTML' first (or avoid `innerHTML = ""' in favor
> of a while-firstChild-removeChild loop), and then assign string values, not
> number values to those short-hand style properties.
I'm not familiar with the idiom "while-firstChild-removeChild loop"
but, yes, I understand your point.
After I applied your comments, things began to work much more as I
expect. The big change I made was this:
I was assigning values to 'top' and 'marginTop,' expecting that the
element with id = 'to' would move up and down as a result. But element
'to' is a row in a table, so that was impossible. The element 'to' is
now a column in that table and holds the proper content.
Instead of assigning style values to the element 'to' (whose innerHTML
holds the content I want to display) I'm now trying to assign those
same style values to the table that contains it: more reasonable than
before.
But it's still not working the way I need it to. The table 'pfix' is
the direct child of <body>. When I give a 'top'/'marginTop' value to
that table, I expect it to move with respect to its parent, <body>,
and therefore /not/ move with respect to the viewport. IOW, I think
that by giving the style property the (approx) value of 'scrollTop' I
should be able to get the table to:
1. move up and down with respect to <body> and
2. remain stationary with respect to the viewport.
So: what stupid thing am I doing wrong that prevents this?
>
> HTH
>
Yes, it surely did help. Thanks very much.
-- ben
Thomas 'PointedEars' Lahn
> Very sorry for the bogus post before.
ACK. Please remove it from the Google Groups archive.
> On Oct 2, 4:52 am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>> lcplben wrote:
>>> The problem shows up in the one-line display of internal variables
>>> just below the small banner on the page:
>>> http://sellmycalls.com/cgi-bin/chain
>>> In the function scroll( ) at line 52 in the source, I am asking for an
>>> element's style values: e.style.top and e.style.marginTop. I know the
>>> element is there: I would exit the function if not.
>>> Earlier in the code, I can retrieve the innerHTML of the element. What
>>> stupid thing am I doing wrong that keeps me from seeing these style
>>> values?
>> Contrary to what you state there, your markup is _not_ Valid
>
> The text of that link is misleading. It's a link to the W3C validator,
> not any claim of mine. Thanks for picking that up.
>
>> you have not escaped ETAGOs
>
> What's an ETAGO?
(Google is your friend.¹) That's short for ETagO delimiter, End Tag Open
delimiter by which the markup parser recognizes an end tag: </
You need to escape those in a SCRIPT element for the markup to be Valid,
because its CDATA content ends there. The most simple way to escape it so
that it makes no real difference to the script engine, is <\/
(This is different in XHTML parsed by an XML parser.)
>> you are not telling us in which environment the problem occurs so as for us
>> to try to reproduce it there.
>
> This problem appears in all of FF 3.5.3 with Firebug 1.4.3, IE7, and
> Safari; under WinXP SP3.
Thanks for the information.
>> [...] it stands to reason that if the setFixHdr() function is called,
>> given a suitable runtime environment the element in question would be
>> formatted and the properties should yield at least the assigned values.
>
> Yes, and now that I've I've assigned strings, not numbers, as you
> suggest that part works just fine now.
:)
>> However, you include a "compliance patch for microsoft browsers" script for
>> IE 7 and earlier, which might interfere there.
>
> I thought that was commented out. Well, it's gone now.
Conditional Comments are considered a comment for all UAs but MSHTML, which
parses it and checks if the condition (here "IE lt 7" -- IE *6* and earlier,
sorry) applies; if yes, the rest of the comment is parsed (and rendered, if
it generates a graphical representation.) They are a way to work around
several bugs in the rather buggy MSHTML layout engine and DOM. The
Conditional Comment was probably there for a good reason; you should not
remove it without checking what it does.
>> For a start, assign to `innerHTML' first (or avoid `innerHTML = ""' in favor
>> of a while-firstChild-removeChild loop), and then assign string values, not
>> number values to those short-hand style properties.
>
> I'm not familiar with the idiom "while-firstChild-removeChild loop" [...]
var o2;
while ((o2 = o.firstChild)) o.removeChild(o2);
> but, yes, I understand your point.
>
> After I applied your comments, things began to work much more as I
> expect. The big change I made was this:
>
> I was assigning values to 'top' and 'marginTop,' expecting that the
> element with id = 'to' would move up and down as a result. But element
> 'to' is a row in a table, so that was impossible.
Ah, somehow I missed this.
> The element 'to' is now a column in that table and holds the proper content.
ACK
> Instead of assigning style values to the element 'to' (whose innerHTML
> holds the content I want to display) I'm now trying to assign those
> same style values to the table that contains it: more reasonable than
> before.
>
> But it's still not working the way I need it to. The table 'pfix' is
> the direct child of <body>. When I give a 'top'/'marginTop' value to
> that table, I expect it to move with respect to its parent, <body>,
> and therefore /not/ move with respect to the viewport. IOW, I think
> that by giving the style property the (approx) value of 'scrollTop' I
> should be able to get the table to:
>
> 1. move up and down with respect to <body> and
> 2. remain stationary with respect to the viewport.
>
> So: what stupid thing am I doing wrong that prevents this?
1. Make your markup Valid. For example, you need to declare HTML 4.01
*Transitional* if you want to use the `target' attribute.
2. You have a misconception about the `margin-top' CSS property (and
the `marginTop' short-hand style property). It defines the margin
between the element and the bottom margin of its previous sibling
in the same flow, if there is any; otherwise between the element
and the padding of its parent element if it is in the same flow.
However, that sibling, which would be div#no_scroll (in CSS terms),
is the child of the BODY element and the BODY element is not
positioned with regard to the viewport (but with regard to
the document.)
<http://www.w3.org/TR/CSS21/box.html#box-dimensions>
Obviously now, you cannot expect the table to stand still because
at some point the margin width as computed from the `scrollTop'
property value must become negative, which is not defined (but has
some peculiar side effects with some layout engines with regard
to paddings and floats).
3. You can't eat the cake and have it.
Either
Forget about dynamic positioning if you want the table to move up
and down with respect to the BODY element
or
Use `position: fixed' and the readily available workaround for
IE < 7 to have the table stationary with respect to the viewport.
Lose the rest of the script code that is used for positioning.
>> HTH
>
> Yes, it surely did help. Thanks very much.
You're welcome :)
Regards,
PointedEars
___________
¹ <http://jibbering.com/faq/#posting>
--
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$8300...@news.demon.co.uk> (2004)
lcplben
wrote:
> lcplben wrote:
> > Very sorry for the bogus post before.
>
> ACK. Please remove it from the Google Groups archive.
I'd love to. How? It seems I need to be a moderator to do so.
> The most simple way to escape it so
> that it makes no real difference to the script engine, is <\/
> (This is different in XHTML parsed by an XML parser.)
I had no idea. Thanks!
> Conditional Comments are considered a comment for all UAs but MSHTML, which
> parses it and checks if the condition (here "IE lt 7" -- IE *6* and earlier,
> sorry) applies;
Oh, yes, of course. Has to be that way. Thx.
>
> > The element 'to' is now a column in that table and holds the proper content.
>
> ACK
You wound me, sirrah!
> 2. You have a misconception about the `margin-top' CSS property (and
> the `marginTop' short-hand style property). It defines the margin
> between the element and the bottom margin of its previous sibling
> in the same flow, if there is any; otherwise between the element
> and the padding of its parent element if it is in the same flow.
OK! Thanks again. No, I didn't understand 'margin-top'.
> However, that sibling, which would be div#no_scroll (in CSS terms),
> is the child of the BODY element and the BODY element is not
> positioned with regard to the viewport (but with regard to
> the document.)
Then I take it that the /only/ way to position stuff in the viewport
is position:fixed. position:absolute has nothing to do with the
viewport.
> <http://www.w3.org/TR/CSS21/box.html#box-dimensions>
> Obviously now, you cannot expect the table to stand still because
> at some point the margin width as computed from the `scrollTop'
> property value must become negative,
No matter, but I have the idea that scrollTop cannot go negative until
it counts up to 2^30-1, right?
> 3. You can't eat the cake and have it.
Just to be clear: I need a datum to stand still with respect to the
viewport. I don't care about its position relative to <body> or
(almost: see below) anything else on the page.
> Use `position: fixed' and the readily available workaround for
> IE < 7 to have the table stationary with respect to the viewport.
> Lose the rest of the script code that is used for positioning.
I would like nothing better. But position:fixed doesn't do it. I need
more! If you'd take a look again at:
www.sellmycalls.com/cgi-bin/chain
you'll see that it comprises a very wide and very confusing --
intricate, you might say, or homogeneous -- table. The table is also
in real life very long top-to-bottom -- hundreds or thousands of
lines, potentially.
So I need to give the guy some help in the form (as I envision it) of
column headings that are always visible; and that are horizontally
positioned such that the column headings always line up vertically
with the data columns they describe.
Take a look again at www.sellmycalls.com/cgi-bin/chain, please. Let
the bold-face row near the top represent these column headings. Scroll
the page left and right. The "column-heading" row doesn't follow the
data columns, as I need it to, because I made it position:fixed. (This
is why I need more than position:fixed; I need positon:fixed-
horizontal and position:fixed-vertical in addition to (not instead of)
just position:fixed.)
So my challenge: to take a column-header element out of the flow and
make it visible always. And /that's/ why my hope, to me, lay (still
lies) in wiggling the element's top.
Any suggestions are, as I hope you can imagine, VERY gratefully
accepted.
Thanks again.
-- ben
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> lcplben wrote:
>> > Very sorry for the bogus post before.
>>
>> ACK. Please remove it from the Google Groups archive.
>
> I'd love to. How? It seems I need to be a moderator to do so.
No. This is an unmoderated Usenet newsgroup. Also, a Usenet moderator is
not the same as a Web forum moderator; the former cannot delete postings
(but needs to approve them before they are posted to the newsgroup), the
latter can.
You are not using a Web forum here, but a newsgroup archive (formerly
DejaNews) with posting feature and also non-Usenet groups (added when Google
took over [and did not change everything for the better that way]).
See also:
- <http://en.wikipedia.org/wiki/Usenet>
- <http://groups.google.com/support/bin/answer.py?hl=en&answer=46854>
(linked as "learn more" following "This is a Usenet newsgroup - "
on the right at
<http://groups.google.com/group/comp.lang.javascript/topics>)
That you are not posting only with e-mail address in the From header
suggests that you have subscribed to the newsgroup at Google Groups;
therefore, you should be able to select the posting's "More options",
then "Remove".
>> > The element 'to' is now a column in that table and holds the proper
>> > content.
>>
>> ACK
>
> You wound me, sirrah!
No offense meant.
"Ack(!)" (AE): Expression of general or unwanted surprise, disgust;
"ACK": Acknowledge; "correct", "I concur", "I understand", "(apologies)
accepted", ...
See also:
- <http://en.wikipedia.org/wiki/ACK>
- <http://catb.org/jargon/html/A/ACK.html>
-
<http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment>
>> However, that sibling, which would be div#no_scroll (in CSS terms),
>> is the child of the BODY element and the BODY element is not
>> positioned with regard to the viewport (but with regard to
>> the document.)
>
> Then I take it that the /only/ way to position stuff in the viewport
> is position:fixed. position:absolute has nothing to do with the
> viewport.
Correct.
>> <http://www.w3.org/TR/CSS21/box.html#box-dimensions>
>
>> Obviously now, you cannot expect the table to stand still because
>> at some point the margin width as computed from the `scrollTop'
>> property value must become negative,
>
> No matter,
Yes, it does matter.
> but I have the idea that scrollTop cannot go negative until
> it counts up to 2^30-1, right?
That question cannot be answered until all DOM implementations are Open
Source. It is moot anyway as the approach is wrong.
>> 3. You can't eat the cake and have it.
>
> Just to be clear: I need a datum to stand still with respect to the
> viewport. I don't care about its position relative to <body> or
> (almost: see below) anything else on the page.
Use `position: fixed' for that datum, then. Not a scripting problem.
>> Use `position: fixed' and the readily available workaround for
>> IE < 7 to have the table stationary with respect to the viewport.
>> Lose the rest of the script code that is used for positioning.
>
> I would like nothing better. But position:fixed doesn't do it. I need
> more! If you'd take a look again at:
>
> www.sellmycalls.com/cgi-bin/chain
>
> you'll see that it comprises a very wide and very confusing --
> intricate, you might say, or homogeneous -- table. The table is also
> in real life very long top-to-bottom -- hundreds or thousands of
> lines, potentially.
That suggests the overall design of the application should be reconsidered;
usually large tables are split up into chunks of pages, and only displayed
whole if the user demands it (e.g., by clicking a link).
> So I need to give the guy some help in the form (as I envision it) of
> column headings that are always visible; and that are horizontally
> positioned such that the column headings always line up vertically
> with the data columns they describe.
Not a scripting problem, or a problem that should primarily be solved with
client-side scripting. The question should better be asked in
comp.infosystems.www.authoring.stylesheets or .misc.
See <http://PointedEars.de/es-matrix#features> for an example of a scrolling
table body (e.g., in Firefox 2.0+). Unfortunately, though, CSS support is
not yet as universal as it should be. (One reason why I provide an index on
top, however as more features are added I may have to implement page-wise
listing as well. Question to all: Do you think that is necessary
[already]?)
PointedEars