Tag Archives: height

How to Use Percentage Sizes for Your FancyBox CodeUnit 13 OCT 2012

I’m a huge fan of the jQuery-driven FancyBox and make use of it in just about all of my web development work.

This is a handy little trick to use percentage (%) values for a fancybox implementation’s width and height, thereby making it easier to specify a fancybox that will work regardless of screen size.

(If you are familiar with fancybox then you are aware that it requires height and width values to be passed to it as pixel values.)

Note that I’m assuming that you are making use of the wonderful jQuery JavaScript library here.

//setting a width of 90% and a height of 75%
var fbwidth = Math.ceil(($(document).width()*90)/100);
var fbheight = Math.ceil(($(document).height()*75)/100);

$('#versioninghistory').fancybox({'type':'iframe','autoScale':true, 'width': fbwidth, 'height':fbheight, 'centerOnScroll':true});

Looking at the snippet above, you’ll see that we are first calculating the pixel value of the desired percentage value based on either the screen width or height (using jQuery’s document related functions), and then passing it through to the fancybox declaration.

Nifty.

Javascript: Why DOCTYPE affects document.body.clientHeight Programming 23 JAN 2009

javascript logoIf you ever make use of the document.body.clientHeight attribute in either your vanilla Javascript or jQuery code, you would have noticed by now that sometimes it returns a ‘correct’ value and other times not.

Often the reason for this discrepancy can be traced to your use of a valid DOCTYPE declaration at the top of your page, which can then further be traced right back to your good old Quirks Mode versus Standards Mode fight.

Most, if not all, browsers have a Quirks Mode (although not all display like Internet Explorer (IE) does), and setting an incorrect DOCTYPE or adding an XML prologue happens to be one of the easiest ways of triggering Quirks Mode rendering.

Now the problem with the document.body.clientHeight either returning a ‘valid’ value or not ties directly into this Quirks mode issue, the reason being that in Quirks Mode, the BODY element is seen as the root element, thus making it the equivalent of the viewport as far as the initial containing block (ICB) is concerned. This means that if you were absolutely positioning something relative to the root, you are in fact using the BODY height/width co-ordinates to position against.

However, in Strict rendering the HTML element is the root element, the ICB, and if you are positioning absolutely to the viewport, then in this case the HTML element takes its height from the viewport and positioning is then done according to it’s dimensions. The BODY element in Strict Mode will not have a height unless you specifically give it one.

So in order to reliably get the browser’s height, perhaps it is best to list various browsers and indicate just how they treat the three main ways of getting browser height information, leaving it up to you to decide as to just which one does the job best for you:

Javascript properties and what they relate to:
Browser window.
innerHeight
document.
body.
clientHeight
document.
documentElement.
clientHeight
Opera 9.5+ strict window document window
Opera 9.5+ quirks window window document
Opera 7-9.2 window window document
Opera 6 window window N/A
Mozilla strict window document window
Mozilla quirks window window document
KHTML window document document
Safari window document document
iCab 3 window document document
iCab 2 window window N/A
IE 6+ strict N/A document window
IE 5-7 quirks N/A window 0
IE 4 N/A window N/A
ICEbrowser window window document
Tkhtml Hv3 window window document
Netscape 4 window N/A N/A