Welcome to WebmasterWorld Guest from 54.224.57.95

Forum Moderators: not2easy

Message Too Old, No Replies

javascript div resize breaking print stylesheet

divs dynamically sized with js are too small in print stylesheet with FF

     
10:14 pm on Mar 9, 2007 (gmt 0)

10+ Year Member



Hi all,

Here's a really obscure problem that maybe nobody has ever experienced before, but I thought I'd throw it out there to see if anybody had any ideas.

I'm working on a site that has two scrolling content divs, one on top of the other. The height of both divs is changed dynamically with JS onLoad and onResize events to accomodate different browser window sizes. It's overly complex I know, but I'm not in charge of such things.

In Firefox, the JS sizing is breaking the print stylesheet, in that when printed, the divs remain a fixed size relating to the actual browser window, regardless of what I specify in the print css. The main css is imported for screen only.

It seems like the Javascript resize is going somewhere else in Firefox's little brain, and that's what it uses for the print layout, regardless of what else I do. I'm sure it's the javascript too, because I can comment out the one line that does the resize, and it's fixed.

Anyway, that's a bizarre one, but if anybody has any thoughts, I'd be interested. Thanks.

9:50 pm on Mar 10, 2007 (gmt 0)

WebmasterWorld Senior Member penders is a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month



...I can comment out the one line that does the resize, and it's fixed.

So, if you can prevent the resize from happening when you are printing (ie. when the print stylesheet is being used) then it should work...?

But how do you detect if the print stylesheet is in use? I guess you can check (in your resize function) for a particular property on an element being set - which is only set in the print stylesheet? And abort the resize if true. Will that work?

Is there a better way to detect if we are printing (cross-browser)?
[webmasterworld.com...]

4:47 pm on Mar 11, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Can't you check the document object, to see what styles are in use?
9:55 pm on Mar 13, 2007 (gmt 0)

10+ Year Member



Hi,

Thanks for the replies. Sorry I didn't respond ealier, but I never got an email saying somebody had replied. I guess I didn't expect anyone too.

I may have been thinking about this the wrong way. I was assuming it was the browser onLoad or window resize that was causing the problem. I figured the print version would come out of cache, only with the print css applied. What you seem to be saying is that when the user goes to print, it actually loads the page again and triggers the onload function. It never occurred to me it would happen that way. Silly me.

So, with this new perspective, I'll be I can figure something out. Thanks for the insights. It's funny how we can have blindspots like that.

10:23 pm on Mar 13, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Absolutely. When you print, it re-renders the page.

Not sure if it does an onLoad, though. I think it just redraws it using new stylesheets.

If it reloaded, all sorts of havoc would be played with AJAX and DHTML stuff.

10:28 pm on Mar 13, 2007 (gmt 0)

10+ Year Member



It was only happening in Firefox, so it must be that FF is calling the page, and the onLoad function is screwing up the div height for the print stylesheet. It also resizes the div based on window.height, so who knows where it gets that from. Maybe from the browser window still.

All very odd, but now that I'm thinking about it the right way, I'll bet I can figure it out.

Thanks.

10:55 pm on Mar 13, 2007 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



It's not OnLoad. I just did a test with the code at the end of this reply, and nothing changes. If OnLoad were being called, there would be either only one, or an extra button. (Mac FF2).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>Test</title>
<script type="text/javascript">
// <![CDATA[
function CreateANewButton(in_old){
if ( typeof ( in_old )!= 'undefined' ) {
in_old.disabled=true;
in_old.value="Spent";
}
var divvie = document.getElementById('next');
divvie.id = '';
var newbutton = document.createElement('input');
newbutton.type = "button";
newbutton.value = "Create New";
newbutton.onclick = new Function ('CreateANewButton(this);');
divvie.appendChild(newbutton);
var newdiv = document.createElement('div');
newdiv.id = "next";
divvie.parentNode.appendChild(newdiv);
}
// ]]>
</script>
</head>
<body onload="CreateANewButton()">
<div>
<form id="test" action="#" method="get">
<div id="form_container">
<div id="next"></div>
</div>
</form>
</div>
</body>
</html>
10:33 pm on Mar 14, 2007 (gmt 0)

10+ Year Member



That's strange, because I can use both the onLoad and onResize functions to hide a page element on the print version. So, it must be calling the function even when printing.

There are several elements (search, nav, header) that won't show in the print version. They're all set to display: none; in the print stylesheet. I was just going to use one of those as a test, and if it's hidden, then I won't call the functions.

Strangely enough, trying to check the display on a div element returns null, even if I specify it display: block; in the external stylesheet. But, if I give it an inline style, i.e. <div style="display: block;">, then my javascript returns it.

I've run into this problem before, but I can't find a solution. OnLoad ought to mean everything's loaded, so all styles should be present. But when the display is specified in the stylesheet and not inline, javascript returns blank.

Like this:

var testVisible = document.getElementById('site-search').style.display;

will return a blank value, even if I specify block in the CSS. If anybody knows the fix for this, I think I'm set.

Thanks.

11:39 pm on Mar 14, 2007 (gmt 0)

WebmasterWorld Senior Member penders is a WebmasterWorld Top Contributor of All Time 5+ Year Member Top Contributors Of The Month



Strangely enough, trying to check the display on a div element returns null, even if I specify it display: block; in the external stylesheet. But, if I give it an inline style, i.e. <div style="display: block;">, then my javascript returns it.

Yes, unfortunately, the 'style' property only reports the value of the inline styles set on the element.

However, there are more general methods to get at the other styles on an element. Unfortunately (again) the methods do vary from IE to FF/Opera, but PPK discusses this rather nicely on his site and presents a simple solution...
[quirksmode.org...]

It's also discussed here...
[webmasterworld.com...]

7:22 pm on Mar 15, 2007 (gmt 0)

10+ Year Member



Thanks penders, that was a good tip. So, now I've got another function to return the display of the given element, which looks like this:

function getCurrentStyle(id, style) {

var element = document.getElementById(id);
var activeStyle;

if (element.currentStyle) {
activeStyle = element.currentStyle[style];
} else if (window.getComputedStyle) {
var compstyle = window.getComputedStyle(element, "");
activeStyle = compstyle.getPropertyValue(style);
}

return activeStyle;

}

Then, I've got a document.write calling that function at the bottom of the page I want to print. In the browser, it returns "block". When printing, it still returns "block", even though the print CSS clearly defines the element as display: none;, and it's hidden in the print version. I've got the stylesheets called like this:

<style type="text/css" media="screen">
@import "css/mtp.css";
</style>
<link rel="stylesheet" type="text/css" media="print" href="css/print.css" />

This is very strange, but it seems like the getComputedStyle function in FF is returning the screen CSS value for display, regardless of what I do.

 

Featured Threads

Hot Threads This Week

Hot Threads This Month