Floating/scrolling image?

[TheAlex]

Does anyone know how to create an image that scrolls with the page, much like this menu on the following link?

http://www.myvue.com/cinemas/index.asp?SessionID=DF03F98209A546809563E5FF5A6B5D4F&ci=52

It's easy enough to do one positioned from the left of the browser window, but the solution I need is where all the content is centered, as on the Vue website, so that the image stays with the left of the table rather than the left of the browser when the browser is resized or the website is viewed on different resolutions. I'm okay at HTML & CSS but my JavaScript is very limited.

That Vue example doesn't work in IE7, and browser compatibility is one of the problems I'm having (I did something using CSS that worked in IE6 but not Firefox/Netscape).

[MattEvans]

well. that's definately JavaScript; and the reason it doesn't work well in all browsers is because all browsers have a different idea of what the relationship between windows, frames and documents is. Often, it's just a case of a different object containing the information...

This is code that works for me, (well; I've never had a problem with it on any browser; that's not to say it's going to work on every browser):

function center(object){
	object.style.top = (getVScroll() + (getHeight()/2))-(object.offsetHeight/2);
}

Looking at it, I'm quite suprised it's never had a problem; but anyway: the way I use that code is to position an absolutely positioned object one time only... To make an object scroll as the scrollbar does, you could use some interpolator math based on the distance between the center of the scrolled window and the center of the object at any time (which is what they do on the vue site to make the bar "gracefully" slide up and down), or you could have the image "snap" into the center always (like this: http://www.siteexperts.com/tips/functions/ts08/page3.asp).

However, you need to make the thing move as the user moves. For that, you need either an event listener or an event invoker. An event listener is the nicest way; they are feedback interfaces that are activated as a response to user or system events, Event invokers are the opposite - at it's roughest, an event invoker just repeatadly sets values in an object (usually using a Timer) and lets the browser deal with re-rendering parts of the page over and over again. Still, you could make it intelligent, and only invoke a change in the graphical layout when a change occurs in the height or offset of the window.

There is an existing listener in some browsers, window.onscroll. if you were to write this in a javascript function:

window.onscroll = function(){center(myObject)};

it would center the object when the user makes a scroll movement. But, onscroll is apparently not supported on all browsers; so catching the "scroll" event across all browsers might be your biggest challenge. Perhaps you'll find the only way you can do it is using a timer :eek:

I'd prescribe some intensive testing of where the onscroll event works and where it doesn't, and where the document.offset property works and where it doesn't, and work with that.

[TheAlex]

Thanks for that. :)

We have found this:
http://dhtmlnirvana.com/oldalchemy/floatlayer.html
which seems to do the job fine - when we remove the W3 doctype code from the top of the document, which of course we need. It also seems to have a problem when include files are on the same page. A bit more tweaking to go then.

[GreenDay2001]

Thanks for that. :)

We have found this:
http://dhtmlnirvana.com/oldalchemy/floatlayer.html
which seems to do the job fine - when we remove the W3 doctype code from the top of the document, which of course we need. It also seems to have a problem when include files are on the same page. A bit more tweaking to go then.

I dont know what you are referring to by thisn post BUT Never remove doctype from your document, its really important and worths.

[TheAlex]

The previous link I posted - http://dhtmlnirvana.com/oldalchemy/floatlayer.html (explained here: http://dhtmlnirvana.com/oldalchemy/floater.htm ) - and other floating layer examples (eg. http://www.yaldex.com/FSBackground/PersistentLayer.htm ) work fine until the web address for the DocType declaration is added.

For example, the floating layer works if the doctype is as follows:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

If the w3 address is added, the floating layer doesn't work...

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

If you look at the HTML source on the above two examples, neither include the w3 address, which renders the declaration pointless? Is it just me, or is this a really strange thing to happen? :eek: Does anyone know if it's possible to have the floating layer AND keep the full doctype statement?

[roryt]

I have never come accross this... How did you actually notice that? Can this not be done with pure css using the fixed selector in the position property?

[TheAlex]

I noticed it by a lot of frustrating trial and error. :lol: The problem with the fixed property is it doesn't work in all browsers (I think it does if the layer is positioned from a browser border, but in this instance, it needs to be positioned from a table element).

[roryt]

Oh right, do you have the solution. Please post it when you find it. I have looked before for this effect and I never found a code to solve it. Let us know.

[TheAlex]

Well, the solutions in the links I provided in the previous post work, but not when the web address is added in the doctype statement. I can't see any way around this at all apart from excluding the doctype statement from the pages that need the floating layer, which isn't really a good idea...

[roryt]

I am sure there must be a way of doing this without excluding the doctype otherwise I doubt that a professional website like vue would do it. Anyone?

[Dal]

THANK YOU TheAlex!

Thats sorted my problem out! Its very strange how the doctype interferes with the floating layer, however removing the full doctype;

<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>

and replacing it with;

<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN'>

Worked a treat. Is it me or is this whole W3C thing a little behind on things? I created a website which was completely W3 Compliant and I ended up having to scrap 6 months work because it didnt work in IE7 or FF2 very well. Therefore I rebuilt the whole thing through a WYSIWYG method and I will at some point try to get it back to a W3 compliance... Theres me thinking that being PC about things would benefit me!

Thanks again for this solution!

[MidiMagic]

And we need this capability why???

[Dal]

Sorry to bring this thread up again but Ive stumbled on something weird

To correct the problem of the float layer not working you can still get away with using the full;

<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>

by putting in a blank comment (or any kind of comment for that matter) in the line before...

<!---->
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>

DONT! Ask me why, I havent a clue as to how it makes it work! I just stumbled upon the res and Im not knocking it.

:confused: :?: :| :)

[MattEvans]

That 'works' because putting anything on the first line of an XML file other than a DOCTYPE renders the DOCTYPE totally ineffective - it will at best be ignored, and doing something like this should throw a decent XML parser into a 'failed' state. Why would you want to specify a DOCTYPE, if all you want to do is disable it?

Also, not specifying the system identifier for a DOCTYPE ( i.e. the 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd' part in the XHTML DT ) turns off the DOCTYPE's effect on a number of browsers, so, that's probably why leaving that part out 'works'.

New-standard DOCTYPES interfere with legacy code and occasionally code written for quirks-mode/nonstandard interpretation; that's to be expected. Get/write modern code, or drop the plans to use a modern DOCTYPE.

To state again, you're not getting any benefit from doing this - if you don't like the effect of the DOCTYPE, remove the DOCTYPE statement completely, and save a handful of bytes in filesize - at your own risk of course.

[Dal]

Thanks MattEvans

I guess Im going to have to go back to frames to make this thing work with W3C and JavaScript!

Thanks for the info, didnt realise that the comment or the half created DOCTYPE would disable it.

Any suggestions on creating a page with a header bar that stays in one place at the top much like a frame or like this float div layer? I need it to be available to the user at any point down the page.

[MattEvans]

This works for me on Opera 9 and Firefox 2. Can't check on IE7 cause I don't have it. Not sure if it's exactly what you're after - noteably, you'll have problems making the top 'div' fill a proper width-of-page because position:fixed; throws the element out-of the size constraints of the page.

<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Sticky bar thing..</title>
<style type="text/css">
.sticky
{
  position:fixed;
  top:0;
  left:0;
  font-weight:bold;
  border:solid 1px black;
  background-color:yellow;
}
</style>
</head>

<body>

<!--the important bit-->

<div class="sticky">I'm gonna stay up here for a while..</div>
<p>
<!--just a load of one `a' per line to pad out the page and force scrolling-->
a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>
</p>
</body>

</html>

[Dal]

Thanks again Matt

FF2 - ok
IE7 - ok
IE6 - Fail

I love the fact that no matter how much we try to compensate for each browser type and version there are always massive amounts of difference. I developed an entire website in IE6 which completed every aspect of W3c and WAI to find that when FF2 and IE7 came out the website fell down.

I guess Ill just have to inform people that this thing Im building will only work in the latest browsers for FF and IE but I havent got around to testing them on the lower used browser types like Netscape:disconned, Opera, Konquerer, MACs, AO'HEL'L and any other low use percentage browsers. (Based on http://www.w3schools.com/browsers/browsers_stats.asp)

I will have to remove the rotation on my text as FF2 just scrambles the page. Wouldnt you think that FF would try to copy the features provided by IE. My audience for the website may be people who do not know alot about PC's and they would be looking at the website through the system provided browser: IE so I plan on making this my primary focus. Unfortunatly I havnt the time to condition my website to suit those who use FF as much as I would like... FF would be my choice after all.

I also have some problems with a WYSIWYG editor (InsiteCreation WYSIWYG Editor 3.0) a popular one which fails sometimes in FF and you have to refresh the page. I hope Ive made my point as to why FF is naff in that sense. Still, I suppose it runs better than IE.

Im getting completely off topic now.

[MattEvans]

<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd'>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Sticky bar thing 2..</title>
<style type="text/css">
.sticky
{
  position:absolute;
  font-weight:bold;
  border:solid 1px black;
  background-color:yellow;
}
</style>
<script type="text/javascript">
//<!--
function get_vertical_scroll( )
{
  if( window.pageYOffset )
    return window.pageYOffset;
  else if ( ( document.documentElement ) && ( document.documentElement.scrollTop ) )
    return document.documentElement.scrollTop;
  else if ( ( document.body ) && ( document.body.scrollTop ) )
    return document.body.scrollTop;
  else
    return 0;
}
function glue( object )
{
object.style.top = ( get_vertical_scroll( ) + 10 ) + "px";
setTimeout( function(){ glue( object ); }, 1 );
}
//-->
</script>
</head>
<body onload="glue( document.getElementById( 'stickme' ) );">

<div id="stickme" class="sticky">I'm gonna stay up here for a while..</div>
<p>
<!--just a load of one `a' per line to pad out the page and force scrolling-->
a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>a<br/>
</p>
</body>
</html>

This works for me in Opera 9, Firefox 2 and Konqueror 3.5.

It uses a messy polled refresh on the object. I really dislike that method, it makes the 'fixed' bar jumpy and it means theres always a bit of background code running ( more than usual, that is ). I'm not sure if it'll work in IE6.. I tried to put in contingency for all the ( known by me ) ways that a browser can represent 'vertical scroll'.

>> I developed an entire website in IE6 which completed every aspect of W3c and WAI to find that when FF2 and IE7 came out the website fell down.

I think lots of developers suffered that.. it's kinda inevitable but unfortunate that with a new release that has new / changed features, some older code will break down.

Personally, I would say aim for IE7, FF2 and Opera9. Leave the other browsers out; users of these browsers know what they're getting themselves in for when they use older/unusual products. IE6 is still quite popular though.

Alternatively.. is this feature really totally necessary, or just a nice added feature? If the feature isn't essential, stick with the elegant CSS alternative and allow it to degrade to the sticky bar being left behind at the top on older browsers ( this should happen automatically ).