Tinsology

In my experience, one of the most common pitfalls for beginning programmers is not understanding the relationships between objects in their environment. This is especially the case in web development where there is in almost every case a blend between multiple client side and server side scripts. Failure to understand the the way browsers and servers communicate or the relationships between (X)HTML (or JavaScript or CSS etc) and PHP (insert alternative language here) will certainly lead to a poor or incorrect implementation. If you are an experienced programmer you probably won’t gain much from reading this, but if you are a beginner, hopefully I can provide some insight that will save you a lot of trouble.

The difference between client side and server side code is fairly simple. Client side code is processed by the client (the browser to be more specific) while server side code is processed by the server. HTML for example is parsed by the browser; the browser is responsible for taking that code and turning it into what you see in your window. For the purposes of parsing web pages, there is a short list of the types of code the browser can deal with. A typical web page, as far as the client is concerned, consists of some flavor of HTML often supplemented by CSS, or JavaScript (an exhaustive list of the types of client side code is beyond the scope of this entry).

Server side code, on the other hand, is never seen by the browser. The browser is not and should never need to be aware of server side scripts such as PHP. While a web page consists of client side code, this code is often either partially or entirely generated by a server side script. For example:

$title = 'Client Side Vs. Server Side Code';
if($title == '')
	echo '<title>Tinsology</title>';
else
	echo "<title>$title</title>";

When you navigate to a page containing the code above the browser will see “<title>Client Side Vs. Server Side Code</title>”. That’s it. The browser does not see any of the PHP code that generated the title. When you request a page containing PHP code from the server, the server first processes that page and then sends the resulting output to the client.

Server side code is browser independent (unless explicitly coded otherwise). This means that if the page you create looks different in Internet Explorer than it does in Opera it has nothing to do with your PHP code, but rather the resulting client side code.

If you’ve ever read a magazine you’ve probably noticed that often the first character on a page stands out. Usually its larger, a different color, or stylized in some way. This effect is called an initial or a drop cap. Using CSS it is fairly simple to achieve this effect. CSS supports the pseudo element “first-letter” which allows you to modify the appearance on the first letter of a paragraph:

p:first-letter {
//style here
}

Notice that the code above will effect the first letter of every paragraph. For the purpose of creating a drop cap effect, we only want the first paragraph to be affected, so we must also use the first-child pseudo class:

p:first-child:first-letter {
//style here
}

Using this method you can now implement a drop cap effect. To do this you first need to decide between two common styles. In some cases the initial falls below the first line, in others the base of the initial is consistent with the base of the rest of the line. With respect to CSS, the difference between the two will be a float.

p:first-child:first-letter {
	/* The float causes the top of the intial to
	be consistent with the rest of the line, while
	the base is allowed to extend below. Removing
	this line will cause the base to line up with
	the rest of the line */
	float: left;
	//style here
}

You can add any of the following properties to your first-letter element:

• font properties
• color properties
• background properties
• word-spacing
• letter-spacing
• text-decoration
• vertical-align
• text-transform
• line-height
• clear

If you decide to use the float, I recommend using the after pseudo element to clear the float following the paragraph. Failing to do so may cause the drop cap the interfere with the following paragraph, if the first paragraph is short.

p:first-child:first-letter {
	float: left;
	//style here
}

p:first-child:after {
	content: "";
	display: block;
	height: 0;
	clear: both;
	visibility: hidden;
}

If you are using this in your WordPress theme, you should specify the class of the div your post is wrapped with. In my case it is the “post” class:

.post p:first-child:first-letter {
	float: left;
	//style here
}

.post p:first-child:after {
	content: "";
	display: block;
	height: 0;
	clear: both;
	visibility: hidden;
}

In addition to this you may also want to use the first-line pseudo element the modify the style of the first line, which is also common in publications. Here is the current drop cap code I’m using:

.post p:first-child:first-letter {
	float:left;
	background-color: #eeeeee;
	line-height:30px;
	padding: 5px;
	color: #237ab2;
	font-weight: bold;
	font-size:40px;
}

.post p:first-child:first-line{
	font-variant: small-caps;
}

.post p:first-child:after {
	content: "";
	display: block;
	height: 0;
	clear: both;
	visibility: hidden;
}

Almost immediately after I started my blog I began having difficulties ensuring that my XHTML would validate. Most of the time I could fix it by modifying the code in a plugin that carelessly preventing my XHTML from validating. Almost always it was something trivial (ie using single quotes instead of double quotes or using CAPS in attributes), however one problem I had persisted for quite a while.

These were the errors I was getting:

• end tag for element “div” which is not open
• XML Parsing Error: Opening and ending tag mismatch: body
• XML Parsing Error: Opening and ending tag mismatch: html

After some effort I realized that this error did not appear on the main page or any of the pages. It only appeared when viewing individual posts. After a while I determined that the cause of this was an extra div closing tag. I also realized that the error only occurred when comments were open, which pointed to comments.php as the source of this problem.

After looking through the code my best guess was that these lines were the source of the error:

<?php endif; // If registration required and not logged in ?>
</div>
<?php endif; // if you delete this the sky will fall on your head ?>

Removing the div from the code above seemed to fix the problem in all but one case. Apparently if a page (not a post) has comments enabled, the extra closing tag was needed and not only did validation fail, but it caused the side bar to fall below page. Making the following change seemed to fix all of the errors (as far as I’m aware):

<?php endif; // If registration required and not logged in ?>
<?php if(is_page()) { echo '</div>'; } ?>
<?php endif; // if you delete this the sky will fall on your head ?>

Keeping up with XHTML validation can be tedious, especially when the people who wrote the plugins you are using might not care about validation. Being able to validate your entire site rather than just a page at one time might ease your suffering and it just so happens that such a validator exists: http://htmlhelp.com/tools/validator/