Center myLayer relative to scroll...

[Chris]

Adding to the code below how would I get myLayer to always display in
the center of the browser regardless of how far the user has scrolled
down the page?

The best I can achieve at the moment is with css top:50% and left:50%
which is not what I want as this causes the page to jump depending on
the page's scrollheight.

Many thanks in advance,

Chris

function showStuff(evt,txt){
var node = (evt.target) ? evt.target : ((evt.srcElement) ?
evt.srcElement : null );
if (node.getAttribute("NAME") == "showlink") {
var myLayer = document.getElementById("myLayer");
myLayer.style.display= "inline";
}
}

 

[David Mark]

Adding to the code below how would I get myLayer to always display in
the center of the browser regardless of how far the user has scrolled
down the page?

This trick is becoming more commonplace and it is always irritating.
Especially when the element won't fit in the viewport and its close
button is out of sight.

The best I can achieve at the moment is with css top:50% and left:50%
which is not what I want as this causes the page to jump depending on
the page's scrollheight.

You can't do it with CSS alone.

Many thanks in advance,

Chris

function showStuff(evt,txt){
var node = (evt.target) ? evt.target : ((evt.srcElement) ?
evt.srcElement : null );

If for some reason srcElement and target are undefined (highly
unlikely), setting node to null won't help the next line (it will
error just the same as if node were undefined.)

if (node.getAttribute("NAME") == "showlink") {

Don't use getAttribute, use node.name.

        var myLayer = document.getElementById("myLayer");

Test that myLayer is not null.

        myLayer.style.display= "inline";

So now you need to attach a scroll listener to the document, which
measures the viewport, gets the current scroll position and updates
the left and top styles of the myLayer element accordingly. See the
FAQ for a fairly good example of how to measure the viewport and a
very good example of how to retrieve the scroll position.

 

[AKS]

You can't do it with CSS alone.

Why not? The simple example:

<style type='text/css'>

#myLayer {
position:fixed;
top:40%;
left:40%;
width:20%;
height:20%;
background-color:black;
}

</style>

<!--[if IE]>

<style type='text/css'>

#myLayer {
position:absolute;
top:expression((document.documentElement.offsetHeight ||
document.body.offsetHeight) / 2.5 +
parseInt((document.documentElement.scrollTop ||
document.body.scrollTop), 10) + 'px');
left:expression((document.documentElement.offsetWidth ||
document.body.offsetWidth) / 2.5 +
parseInt((document.documentElement.scrollLeft ||
document.body.scrollLeft), 10) + 'px');
}

</style>

<![endif]-->

 

[rf]

Why not? The simple example:

top:expression((document.documentElement.offsetHeight ||
document.body.offsetHeight) / 2.5 +
parseInt((document.documentElement.scrollTop ||
document.body.scrollTop), 10) + 'px');

Er, AKS, see the bit inside the expression() part above?

That's javascript.

So your example does not use CSS alone

 

[AKS]

Er, AKS, see the bit inside the expression() part above?

That's javascript.

So your example does not use CSS alone

Wow! I haven't noticed when I wrote it. Thanks a lot!
But seriously, I've always considered it as Microsoft behavioral
extensions to *CSS* (and never as jscript). Because it allows to avoid
technique suggested above: "you need to attach a scroll listener to
the document". Of course, it won't work if jscript will have been
turned off.

 

[David Mark]

You can't do it with CSS alone.

Why not? The simple example:

<style type='text/css'>

#myLayer {
    position:fixed;
    top:40%;
    left:40%;
    width:20%;
    height:20%;
    background-color:black;

}

</style>

<!--[if IE]>

<style type='text/css'>

#myLayer {
    position:absolute;
    top:expression((document.documentElement.offsetHeight ||
        document.body.offsetHeight) / 2.5 +
        parseInt((document.documentElement.scrollTop ||
                  document.body.scrollTop), 10) + 'px');

You don't need the parseInt. The scrollTop property is a number.

[snip]

Technically, this is script. And it won't work in anything but IE
(and with elements that are sized as a percentage of the viewport.)

In general, CSS expressions should be avoided as they are notorious
for inefficiency and sometimes even crashing the browser.

 

[AKS]

You don't need the parseInt. The scrollTop property is a number.

Test these expressions with and without it.

And it won't work in anything but IE

For non-IE browsers I've offered a variant with the fixed positioning
in css.

... sometimes even crashing the browser.

Any other script can sometimes crash the browser. It depends on how it
is written.

 

[David Mark]

Test these expressions with and without it.

I don't care to test CSS expressions. I don't see how converting a
number to a string and then back to a number will help anything.

For non-IE browsers I've offered a variant with the fixed positioning
in css.

You should relegate that variant to IE6 and under as IE7 will support
fixed positioning in standards mode. Assume standards mode and you
can also remove the body part of the equations.

Any other script can sometimes crash the browser. It depends on how it
is written.

Browser crashes are a result of bugs in the browser's code. How
scripts are written doesn't enter into it unless you are talking about
working around specific browser bugs.

IIRC, CSS expressions randomly crashed IE6 until a service pack fixed
it. I wouldn't assume that all IE6 users have that service pack.

 

[AKS]

I don't care to test CSS expressions.

It means: "You don't care about how it'll work after your
recommendations"?

I don't see how converting a

number to a string and then back to a number will help anything.

Once again, test it and you will see the difference (note: it's
necessary to get around some IE bug).

You should relegate that variant to IE6 and under as IE7 will support
fixed positioning in standards mode. Assume standards mode and you
can also remove the body part of the equations.

Actually, I use -behaviors-. And HTC gives more flexibility to solve
this kind of problems. But here I wrote *The simple (means short)
example*.

 

[David Mark]

It means: "You don't care about how it'll work after your
recommendations"?

Is that a question?

number to a string and then back to a number will help anything.

Once again, test it and you will see the difference (note: it's
necessary to get around some IE bug).

That sounds like what I suspected (programming by mystical
incantation.)

I suggest you test it without the parseInt:

#myLayer {
position:absolute;
top:expression((document.documentElement.offsetHeight ||
document.body.offsetHeight) / 2.5 +
(document.documentElement.scrollTop || document.body.scrollTop) +
'px');
left:expression((document.documentElement.offsetWidth ||
document.body.offsetWidth) / 2.5 +
(document.documentElement.scrollLeft || document.body.scrollLeft) +
'px');
}

I suspect it was a lack of parantheses that was causing your issue.
You could have just added them without the parseInt.

And any way you slice it, an element that shrinks and grows with the
viewport is of little practical use.

Actually, I use -behaviors-. And HTC gives more flexibility to solve
this kind of problems. But here I wrote *The simple (means short)
example*.

In any event, it is impossible to do with pure CSS.

 

[AKS]

That sounds like what I suspected (programming by mystical
incantation.)

Yes, in IE it always looks like that.

I suggest you test it without the parseInt:

Thanks for the suggestion, but it will not work.

I suspect it was a lack of parantheses that was causing your issue.

Your unwillingness to test makes you too suspicious.

 

[David Mark]

Yes, in IE it always looks like that.

It certainly will. I've occasionally used CSS expressions in the past
to simulate min-width in IE6. There were no parseInt calls used.
Even if for some reason IE returned a string for scrollLeft/Top (never
heard of such a thing), it wouldn't make sense to convert it to a
number as a string is what you are after in the expression. It seems
you are conjuring a "solution" to a problem you don't understand.

Thanks for the suggestion, but it will not work.


Your unwillingness to test makes you too suspicious.

Why should I test it? It is your code that has the inexplicable bit.

 

[AKS]

Why should I test it? It is your code that has the inexplicable bit.

Take a glance at this article: http://www.howtocreate.co.uk/fixedPosition.html

 

[David Mark]

Take a glance at this article:http://www.howtocreate.co.uk/fixedPosition.html

What a waste of time. No mention of any magical parseInt spells. The
author came up with some other incantation.

Also, the code examples were obscured by horizontal scroll bars. I
hate that.

 

[AKS]

What a waste of time. No mention of any magical parseInt spells. The
author came up with some other incantation.

Mark "Tarquin" Wilton-Jones wrote:

div#fixme {
left: expression( document.body.scrollLeft + 'px' );
top: expression( document.body.scrollTop + 'px' );
}

Due to a bug in Internet Explorer's interpretation of expressions,
it does not update this, so it just stayed at 0,0.
.... I assigned the value to a variable, then used that to assign it to
the expression inline, it did update in Internet Explorer 5.5 and 6.


But I use parseInt instead of using a global variable (and it is
possible to use eval instead of parseInt). That's all.
And now I hope you get me right...

 

[David Mark]

Mark "Tarquin" Wilton-Jones wrote:

  div#fixme {
    left: expression( document.body.scrollLeft + 'px' );
    top: expression( document.body.scrollTop + 'px' );
  }

  Due to a bug in Internet Explorer's interpretation of expressions,
it does  not update this, so it just stayed at 0,0.
... I assigned the value to a variable, then used that to assign it to
the expression inline, it did update in Internet Explorer 5.5 and 6.

So Mark "Tarquin" Wilton-Jones chanted about a variable assignment
that supposedly works around a bug in IE6 and under. He does not
indicate why he thinks his spell works or what bug it works around.
The examples also use CSS child selector hacks, which are clearly
uneeded.

After reading his "theory", I tested my posted version in IE7 and it
worked fine without introducing a variable (or using parseInt.)
Perhaps some workaround is needed for IE6 and under, but I wouldn't
take his word for it. You might want to try it in IE6 as it would be
more efficient than calling parseInt.

But I use parseInt instead of using a global variable (and it is
possible to use eval instead of parseInt). That's all.

You certainly don't want to use eval! These expressions are evaluated
every time you move the mouse. If I had to deal with this problem, I
would start by finding out more about the bug. Is there an MS KB
article on it? If so, what is the recommended workaround? Any
workaround that requires calling eval (or parseInt) every time the
mouse moves is unacceptable.

Luckily, I don't have to deal with this problem as I wouldn't use CSS
expressions to center an element.

 

[AKS]

Perhaps some workaround is needed for IE6 and under...

At last we've found some common point...

You might want to try it in IE6 as it would be
more efficient than calling parseInt.

I don't care about it (as you don't care too). I use .htc (I've
mentioned it above).

You certainly don't want to use eval! These expressions are evaluated
every time you move the mouse.

Thank you. I know, that eval shouldn't be used.

Is there an MS KB
article on it? If so, what is the recommended workaround?

What can they recommend? There is possible to see such examples:

<BR><INPUT TYPE=text ID=oBox3
STYLE="width:expression(eval(oBox1.value) +
eval(oBox2.value));background-color:blue">

Any
workaround that requires calling eval (or parseInt) every time the
mouse moves is unacceptable.

Is this function (parseInt) not quick enough? I think that it works
more quickly any scroll listener.

 

[David Mark]

Is this function (parseInt) not quick enough? I think that it works
more quickly any scroll listener.

The issue with expressions, regardless of what they call, is that they
are evaluated constantly (e.g. on mouse movement.) The code in this
expression (or similar logic in a script) only needs to run when the
document scrolls or the window is resized.

Then there is the possibility of expressions causing crashes, which
may be due to their inherently inefficient design.

 

[AKS]

Then there is the possibility of expressions causing crashes, which
may be due to their inherently inefficient design.

Ok! Your advice are accepted and may be I'll change my mind, despite
of my predisposition to these extensions (because they promised me
"Benefits of Dynamic Properties" ).
Thanks!