Page Sizing

So far we have stepped through a Page Object and tied that object to some event handlers that are triggered when the page is forced to reload. Through this defining the onresize event handled the changing of size of the browser window, and the onorientationchange event handled the same triggers for our Page resizing when a user is on a mobile device.

To start our script off the initial calls to our Page Object were made through an onload event that is triggered when the browser window first loads the document object model or DOM. Through this we are able to call our Page.start function and run through the structure of the Page itself before initializing any objects that we attach to the now blank page.

It is important to note that the onresize event is a pain in the butt with no event handler triggered on the final end of resizing. This is why we have a double function, with the first merely a timer delaying the triggering of the onresize for a reasonable amount of time to ensure the user has decided to stop resizing the browser window. This may see the document redraw itself multiple times during a resize, but not one for every pixel you drag across.

Our output is now a blank page, it does nothing, but it is a script that loaded and started up, and it is a document within the DOM that we can now add objects to at which we can then manipulate using our scripting as well. We will see the importance of this as we run through Page sizing.

From there with our setElements function we laid out a window boundary, and defined the overflow to the whole window as hidden, this gave us control over the window space in total, this means that there will never be a scroll bar in the space, and anything drawn outside the space wont cause the browser to shift the elements around the window if one of them sits outside the windows dimensions.

Defining our window at the core document puts the total of the document object model at our disposal through our newly created Page Object. This can be seen by the way outer and inner elements were laid out in our script and defined to run in the initialization function. This is where we end up with two flat lines displayed on the screen our outer and inner divs taking up a full width although with no defined height. It should be noted here that the DOM compiles from the top left and down, the “scrollWidth” is mostly known at runtime, unless a unique side scrolling site is put into play, it is therefore the “scrollHeight” that is unknown until all the elements have been compiled by the Browser Window.

We must manipulate the display of our elements, especially given that the window space itself is defined to have an overflow of hidden. This is where we start a new Object called DOM and define some functions that will manipulate the elements we have already set in our Page.

var DOM = {
	_VERSION: 	"0.1",
	_CLASS:		"DOM",
	_AUTHOR:	"Steven Spiers",

}

Very simply we have called the page DOM because we are going to create some functions to manipulate the DOM environment. Our first port of call here is the elements we have defined already in our Page Object. They have no height, and are merely lines across the top of the screen, however, we know that they container our outer and inner div containers set in place to hold our pages actual elements.

getWindowHeight: function() {
	if (true) {
		try {
			return document.documentElement.clientHeight;
		} 
		catch (error) {}
	} 
	else {
		try {
			return window.innerHeight;
		} 
		catch (error) {}
	}
	return 0;
},

To be able to give our elements a height value, we need to know the values of the space we want to resize our page elements too. We therefore look at the browser window and get its height using the above function added to our DOM Object. This is where we start to build up a library of manipulation functions such as height and width but also x and y screen coordinates.

The getWindowHeight function above first checks to see if a document exists within the Browser Window space, if a document has not yet been loaded the function then falls back on the height of the Browser Window space itself. In the case of errors we capture them through a callback through a try and catch which obviously attempts to do what is commanded or fallover to catch the errors and then lastly return a zero if no value is defined.

You would then copy this relevent to the document and windows width properties.

Following this, if the element already had a size and you wanted to change it, you would need to know the height of the element. Because an element is drawn from a top left x/y co-ordinate, as discussed it has no height which is why our elements are displaying only their borders resulting in a two pixel high line across the page.

getHeight: function(element) {
	return element.offsetHeight;
},

After being drawn, the element contains an offsetHeight, and defines the drawn height of the element.

We know a few things about our object though, we know it has a width we can define by percentage that will allow resizing of the page elements to occur naturally, and we know that a user has a specific screen size which we can discover. With the document space set to have a hidden overflow we know that our document is the height of the browser window defined by the users screen space. And lastly we have a border which is defined by its thickness and a solid, dotted or dashed line. From this we can do some mathematics and deduce our required element sizes.

redraw: function(){
	wh = DOM.getWindowHeight();
	Page._elements.mindmappanelinner.style.height = (wh - 24) + 'px';
	Page._elements.mindmapdisplayinner.style.height = (wh - 24) + 'px';	
},

This is the important part to a new developer, we have defined the elements within our scripting environment, and doing this set an object within the Page Object to hold those elements. In doing this we can manipulate and hold them during runtime. So rather than searching for the element on the page to then manipulate it, as in the “head” tag shown below.

document.getElementsByTagName("head")[0].appendChild(this._elements.author);

Through what we know about our panel and display elements, and by getting the height of the window we can now define our placement. We know the page boundary has a padding of ten pixels plus the height of the border of the inner and outer elements gives us 24 pixels. Given the element is drawn from its top left, it is already set down ten pixels by the padding of its parent element, our height has to take into consideration the space above the element.

We instead manipulate the element held in our script. With our retrieved Window Height we can subtract our known 24 pixels and then add the string px to the end to conform with the DOM Height variable. The elements height will now be what ever the users window height is minus twenty four pixels.

Page._elements.mindmappanelinner.style.height = (wh - 24) + 'px';

Notice how we have manipulated the inner div, this will become apparent to you as you become more familiar with using this double up concept of a div inside a div. It however will allow you a tad more manipulation over the placement and display of your elements as you add them to the panel and display divs.

By setting the redraw to trigger every time the page is resized and on the inital prepare of the page we can control the screens window space regardless of the way the user maniulates the space. The onresize function should now be familiar to you, our prepare function is triggered on the running of the main script within the Page Object.

onresize: function(){
	this.redraw();
}
prepare: function() {
	this.redraw();
}

This gives us a full height div, with the inner stretching out its parent outer div as well. With percentages set to seperate the two elements from each other, the resizing or changing orientation on a phone will result in a full redraw of the window and then any attached elements within the Pages space.

What this means is our panel and display are stretchable and will always remain set to the windows edges and spaced by the borders we set to those elements. You can see by the image below that the Windows Document retains the panel to the left and display to the right with a border ten pixels in from the windows edge all the way around.

What we have now is a bordered panel on the left and a display window on the right which will stay within the boundaries defined and setup a framework to add further elements to like our display canvas which we will discuss in future lessons.

From this lesson we can see that very quickly one is capable of setting up a framework to further add to that defines the display and nature or functionality of your site. You are not limited to two panels here, your imagination is your limit when it comes to defining how your site is laid out. Saying that, obviously functionality of that site must be the number one priority on that list.

We will try and keep to the KISS principle of keep it simple stupid, even though the subject matter is complicated to many to start with.

«

1 comment

  1. I should have added. If you remove a border you lose height. This is why we make the color transparent and define a border in the first place. This way later, if you decide you want to add that border, you can. This wont shift your elements within the window space by a single pixel making you tear your hair out trying to figure out how to align that one stupid element thats stuck out by one or two pixels.

Leave a comment

Your email address will not be published. Required fields are marked *