With monitor resolutions getting larger and larger, and with the advent of large screen TV’s that can double as computer monitors, web developers have a dilemma. What resolution do you use to build a web site that will look good with all these different resolutions?

It use to be that you built web sites for a 800×600 resolution monitor, those days are gone. Now only about 3% of users have their monitors set at 800×600. The current sweet spot is 1024×768 with 20% of the viewers using this resolution. With more and more people moving to 1280×800 at 19% and 1280×1024 at 15%. The resolutions are all over the place. At this point in time you should optimize your web site design for 1024×768. That means that those folks that are still using 800×600 will have to scroll to see the screen.

The fact that a significant number of users not only have different resolutions, but most are greater than 1024×768 has led web designers to design sites that stretch their width for different resolutions. The CSS term for this type of layout is “liquid layout.” The problem with liquid layouts is that if the screen stretches too wide, and text lines get longer and longer, text becomes difficult to read. The solution for this is the “jello layout,” where the expansion of a web page is limited to a maximum width.

One of the solutions to the changing width is to use a consistent background color to surround your main content. This works and it is the easy way out, the content is set to a maximum width and the background covers whatever width is left. At higher resolutions though this looks ugly, too much background color. The solution is to make your background more interesting with a background picture or composite image, and that’s when you run into some problems.

The traditional way to put a background image on your site is in the CSS file, like so: body {background-image: url(../images/myimage.jpg)}. The only problem with doing that is that you can’t re-size the background image in CSS. To do this you have to move the image to your html file. This allows you to style and re-size your image in the CSS file.

Before we get into how to do this, a word about the background image you will use. If you expect to stretch the background image in width from one resolution to the next, you want an image that is more landscape oriented than portrait oriented. The problem with a portrait image is if you stretch the image too much you will distort the picture, landscape images bend easier in width. You also should scale the image to a size close to the size in width it will be at 1024×768, or 1024px. You can crop the image if it becomes too long in height. Lastly, you should worry about the image load time or the file size, and consider compressing the image to reduce the file size.

OK, we have the image we want for our background set up and ready to go. How do we set the background image to re-size with changing resolutions. First the html structure:

Nothing unusual here. We are inserting an image into the web page right after the body. The tricks are in the CSS, let’s get to that…

* {
	margin: 0;
	padding: 0;
}

body {
	text-align: center;
}

#backimg img {
	position: absolute;
	top: 0;
	left: 0;
	width: 100%;
	z-index: 0;
} 

That’s all there is to it…well, not quite. This will anchor your image to the upper left corner as a start point. The “position: absolute;” takes the image out of other relational groupings with the rest of your web page, and is important to making this work. The width: 100%; tells the browser to stretch the image across the entire monitor window. Well, get to the z-index in a second.

Well, that’s all well and good, if you change browser resolutions, you’ll see the image stretch, depending on your monitor resolution, but how does the content area fit into this set up? Well, the “bodywrap” tags represents the content of your web page. You want that centered in your window with the background image to show on either side of your content. It would be nice if the content would re-size with the background, and well use the same technique to do just that. Here’s the CSS.

#bodywrap {
	position:absolute;
	width: 94%;
	margin-left: 3%;
	margin-right: 3%;
	margin-top: 30px;
	z-index: 20;
}

This will expand your content with a 3% border for your image to show on the edges. Use the margin-top: 30px; if you would like to show a piece of the background image at the top of the screen. If you’d like to have your content have a white backdrop, we need to add another div. It would be background image, then backdrop, then bodywrap for your content, here’s the CSS section for the backdrop, like so…

#backdrop {
	position: absolute;
	background-color: white;
}

Here the color of your backdrop is white and we have also taken the backdrop out of the web page components layout, but it is absolutely embedded in the bodywrap.

Which brings us to the z-index. The z-index tells the browser which layer to put on top of another layer. The higher the number, the more that content block is moved to the front of the screen. Thus our background image is 0 and the bodywrap is in front of that image at a z-index of 20.

Here’s the complete CSS file in a compressed format. Enjoy.

* {margin: 0; padding: 0; }
body {text-align: center; }
#backimg img {position: absolute; top: 0; left: 0; width: 100%;	z-index: 0; }
#bodywrap {position:absolute; width: 94%; margin-left: 3%; margin-right: 3%; margin-top: 30px; z-index: 20; }
#backdrop {position: absolute; background-color: white; }

Before we set some cookies, let’s look at the flow of messages and responses between your computer, and the server, where the web pages are stored. When you click on a link to go to a web site, your browser sends a “HTTP Header” request to the server for that web page. The Header message is variable in length and can get lengthy. The browser sends the HTTP Header, then waits for the server to send a “response header,” followed by the web page. How does the server know that the browser’s Header message is complete so it can respond? A blank line is sent at the end of the HTTP Header. The server when seeing the blank line responds with a “response header,” before passing the page.

Why am I going through this? Because the event that passes the communication baton from browser to server, and back again is a “blank line.” When you pass a cookie to a browser, it is attached to the server’s “response header”, but if a blank line shows up in the web page, before you tell the server to attach the cookie to the response header, you’ll get an error message, something like, “Warning cannot modify header information – headers already sent...” In other words, your command came late, the headers already gone. This can drive you nuts trying to figure out where the bug is in your code, if your not aware of what’s happening. The first thing you want to avoid is a blank line, or even a space at the top of the file before the PHP start tag.

The first step in setting a cookie is to tell the server to attach the cookie to its response header. This is done at the very top of the web page, before any blank lines, or “HTML” or “head” tags, with PHP’s “setcookie” function, like this:

<?php
setcookie( 'message_1', 'I am loaded and ready for bear');
?>

The “setcookie” function can take up to six parameters:

1. “Name”, the name of the cookie, a string, in this case: ‘message_1′ ;

2. “Value”, the value of the cookie, can be a string or number, in this case: ‘I am loaded and ready for bear’ ;

3. “Expire”, when the cookie should expire on the user’s browser. This is expressed in seconds, in linux system time based on seconds since January 1, 1970. I suggest you use a PHP time function, and add to it the number of seconds you’d like the cookie to be active in the browser, or use the browser default, since I’m using Firefox, the browser default is 90 days;

4. “Path”, the path on the server where the cookie will be made available. There’s a lot of files on the server, default is the current path;

5. “Domain”, the domain or url for which the cookie will be available. If you have multiple servers serving pages, on which server will cookie information be made available. The default is the current server.;

6. “Secure”, if you only want the cookie to be sent over a secure connection, like “https://”, set it to “1,” if it’s to be secured, the default is “0,” not secure.

Cookies exist in pairs, a name of the cookie, and its value. The other four parameters are usually not sent, the defaults are used. Normally, only two parameters are passed, name and value.

When your browser receives the cookie from the server it stores it in a set file location on your computer, depending on the browser. When you access that web site again, the browser, if there is a cookie available for that web site, attaches to to the HTTP Header it sends to the server. Cookies are a two-step process, you send it first to set the cookie, and then to get the cookie back you have to ask for the page again.

Ok, we’ve set the cookie in the first response header from the server, how do we get the cookie back from the browser. Well, the cookie, when it comes back, is attached to the HTTP Header, how do we read it? Assuming you’ve refreshed your browser, or asked for the page again. Here’s a block of code to do just that,

// Always check to see if the cookie exists,
// or was not deleted by the user
if (isset($_COOKIE['message_1'])){

   echo "The cookie is loaded: " . $_COOKIE['message_1'] ;
}

If the cookie exists and is set, this will echo: “The cookie is loaded: I am loaded and ready for bear”

You also can set cookies in an array. Here’s an example with the cookie’s expiration time set to 10 days :

setcookie ( "myarray[one]" , "My " , time()+ 60*60*24+10 );
setcookie ( "myarray[two])" , "Funny " , time()+ 60*60*24+10 );
setcookie ( "myarray[three]" , "Valentine ", time()+ 60*60*24+10 );

To retrieve this array, we use a loop thus:

if ( isset($_COOKIE['myarray']) ) {
   foreach ( $_COOKIE['myarray'] as $note ) {
      echo $note ;
   }
}

And the output is: “My Funny Valentine“. And finally you can change a cookies value by calling setcookie() again, or delete the cookie by specifying a time in the past, thus: setcookie( “x”, “” , time() – 3600 ) will delete the cookie.

I mentioned cookies are public. Although, you can not look at them directly with a regular text editor, like notepad, and they can be encrypted, there are cookie management editors you can download to read cookies, and there are TCP/IP tools that you can use to watch the traffic go back and forth to a web site including the cookies with their names and values. Cookies can be useful, just be careful how you use them, and what information you store in them.

Cookies, cookies, cookies, we’ve heard about cookies now for many years, the perenial red herring, used like the threat of a nuclear bomb, to strike fear in the hearts of all who used a personal computer to surf the Internet, maybe not quite that forceful, but never in a favorable light. Cookies were started by Lou Montulli of Netscape in 1994, and they were first used by Netscape to see if a visitor had previously been to their site. Besides the Netscape browser, they were next supported in release 2 of Internet Explorer. Every browser since then has supported cookies. The general public first became aware of cookies early in 1996, and has been suspicious of them ever since then.

Cookies are bits of text information stored on your computer from a site you have visited on the Internet. They are stored in a different folder on your computer depending on what browser you are using, and if you surf the Internet a lot, you can amass quite a few of them. If cookies have such a bad reputation, one has to ask, why do all browsers support cookies?

Cookies offer web site owners and you several advantages. When your browser stores bits of text information from a web page on your computer, it allows the web site to know what page you’ve visited, and choices you’ve made on that page. For example, cookies can keep track what items you have selected in a shopping cart, and keep the list for you, even if don’t return to the site for a couple of weeks or even years, if the cookie is still on your computer. Another example is saving your login information so you don’t have to login every time you return to the site. If you have ever returned to a site, and gotten a “Welcome back, Frank” type of message, you can thank cookies.

For marketing cookies can be used to see what pages you have visited on a web site, the domain or page URL can be stored as you visit every page. Thus was born the often dreaded “DoubleClick” cookie, which can track your Internet usage from one site to the next site and gather a history of your web usage. Some consider this malware, adware, or spyware, whatever you want to call it, and they use programs to remove all the cookies on their computer to “protect” their PC.

And there lies some of the problems with using cookies to retain data. Although cookies are specifically linked to the user, his computer, and his particular browser, they are still, by many, considered to be malware, because they can pass your personal web usage history to marketing organizations, even though, it may seem anomynous, it’s still your history being passed. Cookies are not secure from others, which reminds me to warn you against putting any sensitive user information in cookies. They can be viewed by others.

Users delete cookies with cleaning and malware programs, or by disabling cookies in their browser, because of this, as a way to save information beyond the current session, cookies are unreliable for storing information, and inconsistent in storing information from one user to the next. Besides for marketing reasons, cookies are mainly used to retain user information on a current session. Instead, most websites require a user to log in, and by doing this, the user’s information is retained on the server, instead of on the user’s computer, a safer and quicker way to retain information from one web page to the next, especially for ecommerce.

Nevertheless, cookies can be useful, in retaining information about the user that is non-personal, like your favorite color, or the language you speak, and they can retain this information for a fairly long period of time, thus, they are still in use some 15 years later. Are purpose is to show how to use cookies to store information, which we’ll address in are very next post.

In my last post, we covered the GET method, get is one of two methods used to get information from the client’s browser to the server, the other method being “POST.” You’ll find that “post,” by a wide margin, is the method used by developers, over the less secure, “get.”

The post method is used when you have a large amount of data in your form, and when you want to be more secure with the data, and not have it so visible, as with the “get” method.

Let’s have a little fun and review forms a bit, we’ll start with a form the developer might put on a page for the user to fill out in his browser window. Here’s the body of the html with the form.

Tell Us about Yourself


First Name: 


Last Name: 


 My favorite ice cream flavors are (pick all that you like): 
French Vanilla
Chocolate
Black Rasberry
Vanilla Fudge
Strawberry
Cookie Dough
Coffee

What is your favorite pet?
Dogs
Cats
Horses
Parrots
Snakes
I don't like pets

What is the make of the current car you drive:


Buick
Ford
Chevy
Dodge
Pontiac
Toyota
BMW
Mercedes Benz
Other


Tell us about your favoite hobby and why you like it: 

And here is what the form will look like in the browser. I’ve filled in some example data in the form in the browser window for us to use in the next file. In this case the form action will send the form information to “formctrl.php” which we’ll will use to echo out the data.

Here is the php code, minus the php tags, we’ll use to retrieve the data in the “formctrl.php” file, and then, in this case, echo out the data to the screen. Notice that the syntax to retrieve the data is the same as we used for “get,” except we substitute the word, “post,” instead. The data variable in the post portion comes from the “name” tag in the form for each input method.

In the case of asking for ice cream flavors, we selected more than one choice, so we created an array by putting an [] after the name in he checkbox, called, “checkit[]” To retrieve the data from the array, we initialized an array variable in the next file, “$checked,” and then use a foreach loop, and go through the array one choice at a time to retrieve the choices.

$fname   = $_POST['fname'];                  // First Name
$lname   = $_POST['lname'];                  // Last Name
$checked = array();
$checked  = $_POST['checkit'];              // Ice Flavors
$radsel   = $_POST['radioselect'];           // Favorite Pet
$dropcar   = $_POST['dropdowncar'];      // Car
$note   = $_POST['notes'];                    // Comments

echo "And now let's check the data from the form.";
echo "";
echo "";
echo "Hello, Mr. ". $lname . ",";
echo "";
echo "Or can we call you, ". $fname ."," ;
echo "";
echo "What are some of your favorite ice cream flavors?";
echo ""; 

foreach ($checked as $ic ){
   echo "I like ". $ic ."";
   }

echo "";
echo "And what is your favorite kind of pet? ". $radsel .".";
echo "";
echo "";
echo "Thanks ". $fname.",";
echo "";
echo "Can you give me a ride?  ";
echo "What kind of car do you drive?";
echo "";
echo "Yes, a ".$dropcar .".";
echo "";
echo "Any thing more you'd like to say?: " . $note  ;
echo "";
echo "OK, What ever you say, Let's go! ";

And here is what the output of the above file will look like in the browser window.

I think from the above example you can see why “post” is the most popular method used with forms, the user’s data remains hidden until you specifically get the data in the next file.

We’ve covered passing the user’s information from his browser to a file on the server. We’ll next move on to keeping information about an individual user separate from another user, and retrieving it later.

Last post we talked about how we normally get data into a system with a form. The user enters his information into the form and clicks the submit button. The browser then sends the data to the server.

Back at the server, php sets aside some memory, the server stores the information in that memory location, and calls the next page. That page is what the developer specified in the form command.

Here’s the form again:

In this case, the action parameter tells the server what file to go to next, controller.php.

The more interesting questions are how the browser passes the information to the server, and how the controller.php file gets that information out of memory. Those questions are answered by the method parameter in the form tag, in this case, GET. Get is one of the two methods you can use to get data from the browser to your program file.

The GET method tells the browser to package the site and form data as part of the URL sent to the server calling the next page. For example, if we go to the W3C site at http://www.w3.org/ , and in the Google search box on the right side type, “CSS,” click the magnifying glass, and look at the URL at the top of the page.

You’ll see: “http://www.google.com/search?q=site:w3.org&q=css&search-submit=” The browser packaged the site “w3.org”, the variable data, “css,” and the variable, “search,” into the URL after the “?”

Now, to get this information into the controller.php file with use the php $_GET method.

And here’s how you get the data into the controller.php file:

$searchinfo = $_GET['searchit'];

Notice how the name parameter of the input tag, searchit, is the name of the variable we use to GET the information back out of memory.

if we echo the variable we just created, $searchinfo ,

echo "The search word is: ". $searchinfo;

The answer we get is:

The search word is: css

We’ve passed the data from the form input page to the controller.php page.

Now some thoughts. The best place to use get is with queries, as shown above, not when your passing sensitive information, like your social security number. Why? For obvious reasons, all your information is in the URL for anybody to see. GET is not secure, but for a search box, it’s fast and easy.

Another thing, the URL has a maximum size. Surprising it is mostly set by the browser you use, Internet Explorer is 2048 characters, Firefox is 65,536, Safari is 80,000 and Opera in 190,000. Nothing to really worry about, but its best to keep the “Get” method to short queries back to the server. Get gets a bad rap for messing up the URL line, and putting the data out there for everyone to see. It’s not used that much, except for search queries, mostly form data is posted, which we’ll talk about next.