Let’s consider this standard input field:

<input type="text" value="Text." disabled />

Pretty standard stuff. Your web browser will automatically style it a little, but mostly just prevent the user from editing without any real visual hints. But let’s add some basic CSS to convey the state of the input, and to standardise it across our site and on most platforms. If we add the following CSS:

input[disabled] {
	border: 1px solid #999;
	background-color: #ddd;
}

But wait - our demo uses inline styles, but your browser might not have just styled that properly if we used a full CSS declaration. We don’t set a value for the disabled attribute - it’s a minimized attribute. To get IE to play nicely with it (and for XHTML), we’ll have to set the value to “disabled”:

<input type="text" value="Text." disabled="disabled" />

If possible, just for total compatibility, we can also add a “disabled” class that IE6 will respect and apply styles for correctly.

<input type="text" value="Text." disabled="disabled" class="disabled" />

We can then change the CSS selector we’re using:

input[disabled="disabled"], input.disabled

And we’re done! This works across every major browser - IE6+ and FF1.0+ tested, and Safari 3 / Opera 9.5 should be fine as well. The Sitepoint CSS reference has further information on compatibility, available here.

Finally, if you want to see how Firefox styles disabled fields by default, load up your resource://gre/res/forms.css file (you’ll have to copy and paste it to your address bar). There are a number of lengthy selectors with just a few rules, but here’s the big one, way down the bottom:

button[disabled]:active, button[disabled],
input[type="reset"][disabled]:active,
input[type="reset"][disabled],
input[type="button"][disabled]:active,
input[type="button"][disabled],
select[disabled] > input[type="button"],
select[disabled] > input[type="button"]:active,
input[type="submit"][disabled]:active,
input[type="submit"][disabled] {
  padding: 0px 6px 0px 6px;
  border: 2px outset ButtonFace;
  color: GrayText;
  cursor: inherit;
}

GrayText is actually a system color - it’s defined by the CSS 2.1 specification and supported on and off in various browsers. These “special” color keywords are supposed to match the local system styles - on a Windows machine, for instance, Firefox would use the color: GrayText rule to style text in disabled fields with the same color that the local Windows system uses. A list of options is available on the CSS reference as well.

The Simple HTML DOM Parser is implemented as a simple PHP class and a few helper functions. It supports CSS selector style screen scraping (such as in jQuery), can handle invalid HTML, and even provides a familiar interface to manipulate a DOM.

Here’s a sample of simplehtmldom in action:

$html = file_get_dom('http://www.google.com/');
 
foreach($html->find('a') as $element)
    echo $element->href;

This snippet is fairly self explanatory - file_get_dom() is a simple helper function in the library that fetches the page and constructs a new simplehtmldom object around it. Once the object is available, we can easily use simple CSS selectors to find our elements - in this case, anchors - and iterate over them just as we would with PHP 5’s standard DOM classes. (The equivalent code with the standard DOM classes is twice as long.)

But the library doesn’t stop there - as well as traversing the DOM and extracting information, you can also alter it. Consider this snippet:

$html = str_get_html('
<div id="hello">Hello</div>
<div id="world">World</div>
 
');
 
$html->find('div', 1)->class = 'bar';
 
$html->find('div[id=hello]', 0)->innertext = 'foo';

The library supports many DOM-style approaches for manipulation, from exposing real attributes as shown here, to a few helper methods. It also includes other methods to traverse the current node - children(), parent(), first_child() and so on.

Real scraping? Easy. Here’s their Slashdot sample:

$html = file_get_html('http://slashdot.org/');
 
foreach($html->find('div.article') as $article) {
    $item['title']     = $article->find('div.title', 0)->plaintext;
    $item['intro']    = $article->find('div.intro', 0)->plaintext;
    $item['details'] = $article->find('div.details', 0)->plaintext;
    $articles[] = $item;
}
 
print_r($articles);

And finally, there’s always a simple save mechanism:

$html->save('altered-dom.html');

Ready to get started? Head over to the project website, online documentation or the project page on SourceForge.

But you don’t have to be a web dev guru to build great applications: with just a few simple tricks, you can make your web based interfaces more usable and more visually appealing. Here are a few simple CSS tricks every PHP / web developer should know.

Here’s a quick preview of how we’re going to transform our page:

1. Styling Form Inputs, Buttons
When you pop an <input> onto your page, it’s at the mercy of the end user’s system for appearance, behaviour - even size. For example, Firefox handles unstyled inputs differently from IE, and both take many cues from the local OS styling; the same goes for Safari. This is okay on modern OSes — if you aren’t concerned with controlling your visuals — but quite a few users still run “Classic” interfaces, and it’s especially annoying for buttons. Here are some basic styles you should consider for your inputs.

input {
	padding:3px;
	border:1px solid #F0F0F0;
}

These will first add a bit of padding to your text boxes and buttons, and set in stone your border color to a soft gray. In particular, most browsers will render a clean rectangular button with this style present. Consider defining a width in pixels or percents (if inside a container) as well.

2. Styling Tables
Remember to style tables nicely, with table row hover colors, reasonable borders and maybe even striped tables. After all, tables can be dull and boring:

There are two key areas to this: using semantic markup, and taking advantage of CSS selectors. Let’s first fix up our table HTML:

<table border="1">
<thead>
<tr>
<td>Heading 1</td>
<td>Heading 2</td>
</tr>
</thead>
<tbody>
<tr>
<td>Value</td>
<td>Value</td>
</tr>
<tr>
<td>Value</td>
<td>Value</td>
</tr>
</tbody>
</table>

And then add some styles:

table {
	border-collapse: collapse;
	border: 1px solid #CCC;
	font-size: 12px;
}
 
table thead td {
	font-weight: bold;
	background: #E1E1E1;
}
 
table tbody tr:hover td {
	background-color: #F3F3F3;
}
 
table td {
	padding: 5px 10px;
}

First, notice the use of border collapse - this prevents the blocky double-borders on cells. Next, we take advantage of our <thead> and <tbody> to apply a background color to our header row, but a hover effect on body rows. The :hover is on the table row, but the actual background needs to be applied to the cell. Finally, we add a neat padding that keeps text in order. A smaller font size on your table will also cut it down to size and fit more figures on a page.

3. Button Links
Often you want a button-style link to execute a simple action or lead the user to another page. Let’s create a simple “Next” link with this markup:

<a href="#" class="button">Next &raquo;</a>

We can then style it nicely with this CSS:

a.button {
	background: #AAA;
	color: #FFF;
	padding: 3px 5px;
}
 
a.button:hover {
	background: #888;
}

We first set a simple background color on the anchor to make it stand out, and ensure the text is still visible. However, feedback is important here - by adding a simple hover color, we make it clear that this is an interface element and not some ordinary link.

4. Typography
It isn’t hard to use simple, clean text on your pages, as opposed to the serif-heavy fonts IE and Firefox will default to on Win/Linux. Try adding this to your main stylesheet:

body {
	font-family: Arial;
	font-size: 95%;
}

Arial isn’t terribly fantastic, but it isn’t too bad either. (Verdana is also a standard option.) By explicitly setting a font here, you avoid leaving at the mercy of the browser/OS, especially when you may not have testing machines of a particular OS available (e.g. OS X).

With all these techniques in play, we have a nice and usable interface:

Joe Kral
Created: Facebook Logo
History: Like the Facebook brand? Well Joe Kral is credited with creating it back in 2005 before Facebook was FACEBOOK.

Name: Milton Glaser
Created: I Love New York
History: Milton created the ubiquitous I Love New York campaign that’s been ripped off by everyone from Philadelphia to NewYoungPonyClub

Name: Lindon Leader
Created: FedEx Logo
History: In the past few years the FedEx logo has become almost more recognizable than the U.S.P.S itself!

Name: Paul Rand (a.k.a Peretz Rosenbaum)
Created: IBM Logo
History: Even after his death in 1996, Paul Rand remains one of the most famous graphic designers in the world. He designed many posters and corporate identities, including the logos for IBM, UPS and ABC.

Name: Paula Scher
Created: Various Album Covers, Citi Group Logo
History: Paula Scher studied at the Tyler School of Art in Philadelphia and began her graphic design career as a record cover art director at both Atlantic and CBS Records in the 1970s.

Name: Ruth Kedar
Created: The Original Google Logo
History: Ruth Kedar is an artist and designer, best known for designing the Google logo. Her master thesis in school was on Playing cards design, and she was commissioned by Adobe Systems to be one of the designers of the Adobe Deck. She went on to design the award winning Analog Deck and Duolog Deck.

Name: Dennis Hwang (a.k.a Hwang Jeong-mok)
Created: Google’s Specialty Logos
History: Hwang’s actual position in Google’s early days was as their webmaster. He began creating custom logos for the company in 2000 at Larry Page and Sergey Prin’s request.

Name: Rob Janoff
Created: The Apple Logo
History: While it is generally accepted to have been in reference to Isaac Newton, a curious urban legend exists that the bitten apple is a homage to the mathematician Alan Turing, who committed suicide by eating an apple he had laced with cyanide. Turing is regarded as one of the fathers of the computer.

What sets PDF Portfolios apart from other solutions like Powerpoint, Keynote, Illustrator and Word is the ease of navigation and customization it applies to ‘files’, where as most other solutions only let you embed content, offering little control over how it’s displayed once embedded. Click the image for a live demo.

Caching alleviates the latency issue to some extent, but retrieving more than a few files is always going to be a problem, and, well, sometimes users just can’t wait. cURL’s parallel processing allows you to fire off multiple requests at a time and handle responses as they arrive, instead of linear operations - waiting for each request to complete (or worse, time out) before starting the next.

Consider this basic cURL example:

<?php
$ch = curl_init();
 
curl_setopt($ch, CURLOPT_URL, "http://example.com/");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
 
$data = curl_exec($ch);
 
curl_close($ch);
?>

This will fetch the initial resource of http://example.com/ and put the data (the HTML) in $data. If we wanted to do this multiple times, we could use a simple for loop around this code block and repeat. However, through this method script execution time increases are linear, proportionate to the latencies of each network request, and latencies of 50-100ms x 10 requests don’t help when you barely spend <10ms executing all your PHP code.

Instead, we’ll use cURL’s parallel processing system. This requires a bit of a context shift - instead of running each operation, you now have to tell cURL all the operations to run, let it do it’s stuff, and then continue on once it has finished. The difference is that it doesn’t wait for each request - it runs them all simultaneously (network permitting). Here’s a basic example:

<?php
// Create two cURL handlers
$ch1 = curl_init(); $ch2 = curl_init();
 
// Set options on both
curl_setopt($ch1, CURLOPT_URL, "http://example.com/");
curl_setopt($ch2, CURLOPT_URL, "http://example2.com/");
curl_setopt($ch1, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch2, CURLOPT_RETURNTRANSFER, 1);
 
$mh = curl_multi_init();
curl_multi_add_handle($mh,$ch1);
curl_multi_add_handle($mh,$ch2);
 
$running=null;
do {
    curl_multi_exec($mh,$running);
} while ($running > 0);
 
$data1 = curl_multi_getcontent($ch1);
$data2 = curl_multi_getcontent($ch2);
 
curl_multi_remove_handle($ch1);
curl_multi_remove_handle($ch2);
curl_multi_close($mh);
?>

Here, we first create a cURL connection object for each request we want to make - an array of these is perfectly acceptable - and set the options on each. Instead of curl_init(), we then call curl_multi_init() and point the library at each of our connection objects. We have to cede control from cURL at this point: curl_multi_exec() now runs all the sub-connections of the current cURL object - that is, $ch1 and $ch2.

The curl_multi_exec() function takes a second parameter, a reference to a flag of whether operations are still running. When that parameter - for us, $running - is 0, cURL’s finished taking care of requests and we can proceed. Timeouts are the only concern - remember to set the timeout option to a reasonable value to avoid being held up by requests that won’t complete.

As you increase in requests, however, remember that the next bottleneck you will hit is memory. Given PHP’s memory_limit flag (especially on shared servers), you can actually hit this quicker than you think. cURL can’t read part of a file or stream, even if it’s packet-based. Ever seen fread($handle, 8192)? The second parameter results in 8KB chunks, avoiding memory limits elegantly. cURL, however, will simply collect up all your request responses: if you hit your memory limit, you either get a fatal error or a “white screen of death”. Consider parallel cURL-ing in a background process. Also, these simple routines can get quite lengthy - consider building an abstraction layer for your app/framework, to maintain an array of cURL connection objects and interface requests.

Parallel HTTP requests in cURL are quick and easy, despite the architectural differences with libraries for single-threaded cURL. To learn more, just check out the detailed documentation on the PHP manual page.

1. ReCSS
ReCSS makes testing out CSS hacks easy. When you alter your CSS in an editor and save the new stylesheet, you have to reload the entire page in your browser to see the effect of the changes. Sure, you can make the edits in Firebug, but Firebug’s inbuilt editor isn’t great for much beyond the slight tweak. With AJAX-powered pages and dynamic state, reloading the page isn’t quite as simple as it sounds.

Enter ReCSS: this handy little bookmarklet will keep your existing page entirely intact, but reload all the CSS sheets. You may see a brief flash of white in your browser as current styles are removed, before your page renders almost immediately with the latest set of CSS rules. Check out the project page.

2. Layout Grid Bookmarklet
Working out pixels and laying out a page is tricky, especially when working from detailed Photoshop mockups and sketches. After some suggestions from the community about using a background image of a grid for layout, Andy Budd created the Layout Grid Bookmarklet, which creates a drawing-paper style grid against the background of your page to generally measure elements with. Check out his blog post about it and the Layout Grid Bookmarklet.

3. XRAY
X-RAY is a great Firebug/Safari/IE Dev-bar style inspector for web pages. It features a simple point-and-click interface, revealing some basic CSS properties and inheritance hierarchy of the selected element, as well as outlining it and displaying dimensions details. The actual interface is quite slick, and hides away neatly when you no longer want it. If you aren’t at your preferred Firebug-equipped machine, XRAY is definitely something to have on hand. Check out the project page and the XRAY bookmarklet.

4. Aardvark
Aardvark is similar to XRAY, but provides a lot more functionality for traversing the DOM visually. Ever wanted to pick a particular element, then see what happens if you move up n levels, go to the next node across, or even dive in and start editing innerHTML there and then? Aardvark provides a point-and-click interface similar to XRAY, and then a set of keyboard shortcuts for moving around, focusing on finding what you need. Aardvark is actually available as a Firefox extension, although the bookmarklet is quite convenient. Head to the project page and try the Aardvark bookmarklet.

5. Slayeroffice Favelet Suite
We’ve saved the best till last - this favelet suite will blow you away. It features everything from DOM charts to mouseover inspectors, color lists to font resizers, rulers and even a hidden field modifier. All in all, this collection of 15 utilities all in the one bookmarklet is a must for any front-end web development. While it was last revised in 2004, it in many ways offers far more functionality than Firebug, with far more detail provided by its various tools. When you’ve finished with it it, just hit escape to quietly hide it away. Head to the project page and grab the Favelet suite.

FirePHP is implemented as a native Firefox extension, and is available from Mozilla Addons. After a basic setup procedure, you can start printing everything from status messages to multi-dimensional arrays straight to your Firebug console. FirePHP achieves this using extension HTTP headers - in particular, X-FirePHP-Data headers in the response.

The PHP library provides a function, fb(), which handles sending data across to the client side. From here, you simply open up your Firebug console, and your data is displayed in a highly functional manner.

To get started with FirePHP, grab the extension from Mozilla Addons and the core library from the FirePHP project page (the “Download” link). You’ll need to install Firebug first, then the FirePHP Firefox addon. Next we get to the PHP library - either add the “FirePHPCore” folder to somewhere in your include_path, or just pop it into your script directory, and include it:

require('FirePHPCore/fb.php');

Remember to change the relative path as required (no pun intended). Then, simply call the fb() function anywhere in your code, passing a single argument - the info you want to send to your FirePHP console. Here are some examples:

fb('The value of $var is '.$var);
fb('Just logging this event.',FirePHP::LOG);
fb('Error in the email module.',FirePHP::ERROR);
fb($_SERVER, '$_SERVER array', FirePHP::LOG);
 
try {
  throw new Exception('Exception');
} catch(Exception $e) {
  fb($e);
}

As you can see, we can output basic messages, use Firebug’s standard styles to identify message importance (also, INFO and WARN), output labelled assocative arrays, and even debug exceptions - FirePHP will display a neat little stack trace.

Remember that this information is sent via headers, so it needs to be output before any of your HTML. If you’re using a framework with view templates, this is probably not an issue, but otherwise, you can get around the problem by using output buffering. Just run this line somewhere near the beginning of your script execution:

ob_start();

This will initialise output buffering, so that any HTML you output is held up till the end of script execution (or till the next call to ob_flush() and derivatives). Calling the fb() function will then work fine any time before the end of your script, as the headers will be flushed immediately. (Alternatively you can use php_flag output_buffering on in your .htaccess / apache virtual host configuration.)

FirePHP has all sorts of neat tips and tricks - just check out the quick start guide and protocol reference. If you use the Zend Framework, have a look at the Zend library for FirePHP; similar libraries exist for Symfony and Prado as well.

CSSTypeset
CSSTypset is handy tool for seeing the effect of CSS code while simultaneously seeing what’s going on behind the scenes with the actual code. It works both ways, you can type code and immediately see it applied to text, or you can type text and use a GUI with sliders to apply CSS to your text. If you have a hard time figuring out the difference between em and px, verdana and helvetica then this is the tool for you.

Text2PNG
Add a few lines of javascript to your header and this nifty web tool converts your headlines to images automatically.

CSSTextWrap
Sick of ‘designing to an invisible grid’? Turn that grid into origami and spice up your layouts with this incredible text wrap tool.

Kotatsu
A wrote a tutorial a while back about how to make XHTML tables that could be marked up with PHP, Javascript or Ajax. If only I had known about this tool then! Essentially it’s a HTML table generator.

GoldenRationCalculator
Divine proportions have been used for all types of creative work, from architecture to print layout to photography. It’s only natural that it also eventually found it’s way into web design. This web generator makes it easy to design using the ‘golden ratio’ as the underlying framework for your website’s design.

When we want some kind of background process running our PHP code, we have a simple challenge: we can’t leave it up to the client. On the web, people hit their stop button, their browsers lock up and they force quit, they even have the odd power outage. When we want to do complex processing on the server side, we need to detach from the client-server model of a web-served script. PHP can fork a script, but the parent script is still facing an unreliable client.

Our best option, then, is to launch a background process from the command line. There are three steps to this: starting the background script, passing it information to do its job, and checking when it’s finished.

Starting the background script
On UNIX systems, we can easily call another PHP script via the shell, set it to run off in the background and send its output to /dev/null. Here’s a sample:

exec ("/usr/bin/php proc.php >/dev/null &");

Here, we call the exec function; instructing it to run our local PHP binary - usually at /usr/bin/php or /usr/local/bin/php, check with your host/sysadmin. We pass it a single argument: the filename of the PHP script that handles our background process. We then send the output to /dev/null, effectively destroying it. The last character, the & symbol, is important - this tells the system to start this process in the background and to let us continue.

Talking to the background process
It’s all very well to start a background process, but now it needs to know what to do. We handle this through command line arguments. Let’s update the previous example:

exec ("/usr/bin/php proc.php --task=50 >/dev/null &");

Our proc.php file might look like this:

<?php
echo "Handling process ".$argv[1];

Running “php proc.php –task=50″ on command line produces the following output:

Handling process --task=50

From here, you can easily design your script to do what it needs to.

Monitoring the background process
There’s just one last detail: how do we monitor the progress of our background process? It’s best to use an independent datastore that can be relied upon, instead of communicating with running threads - your application’s MySQL database would be perfect. You can create a “sessions” or “jobs” table with an ID column, a status column (started, in progress, finished - 0, 1, 2), and any other information you need. Before you start your background process, create a new entry in this table and check the insert ID, then pass it to the background process when you start it:

exec ("/usr/bin/php proc.php --some_info=50 --job=1234 >/dev/null &");

Your proc.php file can then update the table row with the ID you supply it, and your front end applications can provide status updates to end users by checking up on all pending jobs for the current user - relatively straightforward business logic.

If you’re going to be running many background processes, a job queue and an “always-on” script running on your server may also be an option. In this case, consider looking into pcntl_fork() and the program execution functions.