June 30, 2008
CSS, HTML
No Comments
No, this has nothing to do with the aftermath of the Macy's Thanksgiving Day Parade. This is about that annoying thing with floated HTML elements within a container element, whereby it seems that said container has no inkling of the fact that it should expand enough vertically to contain any and all such floated elements.
I used to address this via the common Band-Aid of inserting a non-floated element just before the closing tag of the container, and giving that new element the clear: both; CSS property:
<div id='container'>
<p class='float'>This element has a float:left or float:right;" style property.</p>
<div class='clear'></div> <!-- "clear" class has the "clear:both;" style -->
</div>
But lo and behold, I recently discovered a simpler solution that does not require any extraneous, empty HTML mark-up, thanks to this article at quirksmode.com. Now I can get rid of that semantically useless <div class='clear'></div> line in the above HTML, and instead just make sure the style for the "container" div includes:
#container {
width: 100%;
overflow: auto;
}
June 29, 2008
Beginners' Corner, Debugging
3 Comments
[2008/07/15: Added this to the "Beginners' Corner" category]
A common problem I see new PHP users running into is having a script output absolutely nothing: the dreaded "blank page" syndrome. This is normally due to a syntax error of some sort generating a fatal parse error. As this error is generated before any of the script is actually executed, none of the file's output ever gets sent to the browser. If the current PHP environment on the server has display_errors turned off, then not even the error message generated by the parser gets displayed. Additionally, since no PHP commands actually get executed when there is a parse error, turning on display_errors within that script via the ini_set() function will make no difference.
The two usual approaches to debugging such problems are to either search the PHP or web server error logs to look for relevant error messages, or else to turn on display_errors, either globally in the php.ini file or at the directory level via a .htaccess file, assuming you are running under Apache and the necessary Apache settings are in effect to allow this. (A third alternative is to use an editor that has PHP syntax checking built in, such as PHPDesigner.)
If for some reason none of those approaches is practical for your situation, a simple way to have any parse errors be displayed is to create a tiny wrapper script that includes the offending file:
<?php
ini_set('display_errors', 1);
error_reporting(E_ALL | E_STRICT);
include 'path/to/flawed/file.php';
?>
All you have to do is run this script in your browser, et voilà, your parse errors will now be displayed.
June 29, 2008
General
No Comments
Yes, I've decided to join the world of blogging.
The intent of this blog will is to pass along any words of wisdom or wit I may come up with during my continuing journey in the world of web application development, in particular in regards to the use of the PHP programming language. You can find more articles and code samples in the PHP and MySQL section of my web site.
I am a moderator at the PHPBuilder forums (under the user name “NogDog”) and encourage you to visit there if you’d like to learn more.
I am available for freelance work. If interested, please use my “Email Me” page to let me know something about your needs, and we can begin a dialog about how best to attain them.