why can't I retrieve style properties from DOM?

[lcplben]

Hi everyone --

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

 

[Thomas 'PointedEars' Lahn]

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 (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

 

[lcplben]

http://sellmycalls.com/cgi-bin/chain


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 anissue.)

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, <[email protected]>

 

[lcplben]

Very sorry for the bogus post before.

 http://sellmycalls.com/cgi-bin/chain


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.

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.


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.)

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.

Yes, it surely did help. Thanks very much.

You're welcome


Regards,

PointedEars
___________
¹ <http://jibbering.com/faq/#posting>

 

[lcplben]

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.

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

   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]

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".

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>
-

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.


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.

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.

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