It struck me that it would be easier to work through this kind of CSS problem with some kind of simple tool to show how a page was put together. If I could see all the tags on the page in a nested format, with parent and child relationships obvious, and without all the text getting in the way, my life would be easier.

So, I put together this tool. In simple terms, it will fetch a page from a web server and output the tags within the page in a nested list. The JavaScript side of it will also highlight children of an element when you hover over it.

Classes and ids attributes are highlighted, as are tag names. Class and ID names, though, must be enclosed in quotation marks to be highlighted. Text, closing tags and line breaks are not shown. Though I can understand some people may find it useful to see text, I found it made the tree too large to be usable.

I've used it a few times, and am quickly finding it saves quite a lot of time solving simple CSS problems or conflicts. Which is exactly what it was supposed to do. Enjoy!

Highlighting Issues

When writing the tool, I came across a fairly unusual problem. I wanted, when the mouse was over an element, to highlight its children. However, this cannot be done with CSS (at least, I couldn't think of a way to make it work).

The problem with the CSS was that whenever you hover over an element, you are also hovering over its parents. So they, and their children, are highlighted - meaning everything is highlighted. For this reason, the highlighting of elements uses JavaScript.

How to Use

The page structure tool is written to accept a URL either by GET or POST. You can therefore use it one of two ways.

First, you can use the tool by visiting the URL below, replacing "##url##" with the address of the page you want to view:

http://www.addedbytes.com/view_structure.php?url=##url##

Alternatively, you can use the following form to submit an address to the page:

Bookmarklet

To make life a little easier, I've coded a quick JavaScript bookmarklet for you to use, that, when activated, will automatically submit the URL of the page you are viewing to the tool. Simply copy or drag the link below to your links bar, your favourites folder or anywhere else you wish:

• View Page Structure

Notes

• This tool works best with valid code, especially XHTML.
• A certain amount of basic code improvement is done before processing (for example all empty tags are automatically closed).
• Sites with non-empty tags that aren't closed properly may not show up correctly.
• Sites with large amounts of nested code should still show up, but it may be difficult to view the output.

Example

If you want to see an example of the output of this tool, you can view the structure for AddedBytes.com.

Note: Many people may consider "validation errors" unimportant. However, if you are going to write a web page in a specific language it makes sense to actually use that language properly, rather than making up your own random dialect. After all, can you be sure that that dialect will be interpreted the same way every single time? Any while many people find errors like this easy to ignore, they should remember that while they might not stop a page being usable, what validators bring up are "coding errors" - mistakes in the markup of the page.

These scripts are intended to make life a touch easier for busy developers. Of course, these scripts will slow down your site, and are no substitute for actually writing valid code in the first place. They are intended to catch the occasional bug that you may have missed, or that may be introduced through a comments system, for example.

In order to make use of the following code, you will need to be using PHP 4 or higher on Apache. The following scripts make use of output buffering and work best with a caching system in place as well.

This script will not remove all of your validation errors. It cannot remove them all without running very slowly - there is a lot to check in each document. However, it can catch a few of the more common bugs that most designers miss at least once in a website.

To begin, the scripts we use start output buffering. This means that rather than send the page to the user as it is created, the page is saved on the server until the server is told to output the page (or the script ends). This will allow us to modify page output without needing to worry about editing the PHP behind it. To start output buffering, you need to include the following code at the top of each page. You can include it using the "include()" or "require()" functions, or using htaccess's superb auto_prepend_file function (which you can see in use in this caching tutorial).

ob_start();

After the script has run, we need to include another script at the end to process the page and output it to the user. You can, again, use "include()" or "require()", or auto_append_file in htaccess to include this script.

The script itself runs in three steps. The first step, below, grabs the contents of the output buffer. This will create a variable called "$output" that contains the page we were about to send to the user. $output contains the HTML after all PHP has run as normal, so the variable literally only contains what the user would normally see. The second line empties the output buffer (but does not send its contents to the user).

$output = ob_get_contents();
$output = trim($output);
ob_end_clean();

Now $output contains the page we are about to send the user, it is time to run the various checks we want, to make sure there are no validation errors in place.

if ((strpos($output, "<!DOCTYPE") > strpos($output, "<html")) or (strpos($output, "<!DOCTYPE") === false)) {
    $output = str_replace('$lt;html', "$lt;!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"http://www.w3.org/TR/html4/loose.dtd\">\n$lt;html", $output);
}

First, we check for a DTD. These are important, as they tell the user agent (e.g. the browser) what language a page is written in. The above checks for the presence of a DTD before the <html> tag, and if it is missing it adds in the DTD for HTML 4.01 Transitional - probably the most common one in use today.

function encode_chars($text) {
    $text = str_replace("<", "&lt;", $text);

    $tag_list = '((\/?)(!DOCTYPE|!--|a(bbr|cronym|ddress|pplet|rea)?|b(ase(font)?|do|ig|lockquote|ody|r|utton)?|c(aption|enter|ite|(o(de|l(group)?)))|d(d|el|fn|i(r|v)|l|t)|em|f(ieldset|o(nt|rm)|rame(set)?)|h(1|2|3|4|5|6|ead|r|tml)|i(frame|mg|n(put|s)|sindex)?|kbd|l(abel|egend|i(nk)?)|m(ap|e(nu|ta))|no(frames|script)|o(bject|l|pt(group|ion))|p(aram|re)?|q|s(amp|cript|elect|mall|pan|t(r(ike|ong)|yle)|u(b|p))|t(able|body|d|extarea|foot|h|itle|r|t)|u(l)?|var)([^>]*))';

    $text = preg_replace("/(&lt;)" . $tag_list . "(>)/mi", "<$2>", $text);
    $text = preg_replace("/(>[^<]*)>/mi", "$1&gt;", $text);
    $text = str_replace("/>", ">", $text);

    return $text;
}

$output = encode_chars($output);

Next, we run a function on the script to check the tags on the page. Any tags that don't belong there are encoded so they are displayed rather than processed. We use the HTML 4.01 tag list, which means we will catch the worst of the invalid tags.

$output = preg_replace("/<img([^>]*)alt=([^>]*)>/im", "<img$1`alt=$2>", $output);
$output = preg_replace("/<img([^`|>]*)>/im", "<img alt=\" \"$1>", $output);
$output = preg_replace("/<img([^>]*)`alt=([^>]*)>/im", "<img$1alt=$2>", $output);

This small snippet of code checks for alt attributes on images. If they are missing, it adds a single space as an alt attribute. This is by no means optimal (and the regex and technique is ugly - if anyone can improve on this, please give me a shout!), however does mean that if an alt attribute is missed, screen readers will not simply give the name of the image file. You should always take the greatest care to ensure that all images have appropriate alt attributes.

Next, we do a little language-specific work. In the above code, we removed all closing slashes (e.g. in a <br /> tag). Now, if we are using XHTML, we add them back in for the appropriate elements. We also check the case of elements if using XHTML, as tags and attributes must be lower case in XHTML. This will only affect attributes whose values are quoted.

function process_attributes($text) {
    return preg_replace("/ ([a-z]+)=\"([^( |\")]*)\"/mie", "' ' . strtolower('$1') . '=\"' . stripslashes('$2') . '\"'", $text);
}

if (strpos($output, "//W3C//DTD XHTML") !== false) {
    $output = encode_chars($output, "XHTML");
    $output = preg_replace("/<(img|hr|meta|link|br|base|frame|input)([^>]*)>/mi", "<$1$2 />", $output);
    $output = preg_replace("/<(\/?)([a-z]+)( |>)/mie", "'<$1' . strtolower('$2') . '$3'", $output);
    $output = preg_replace("/<([^>]+)>/mie", "'<'.process_attributes(stripslashes('$1')).'>'", $output);
    $output = preg_replace("/&(?!#?[xX]?(?:[0-9a-fA-F]+|\w{1,8});)/i", "&", $output);
}

We also, at the end, encode any ampersands that should be encoded. Many thanks to [url=http://www.shauninman.com]Shaun Inman[/url] for the last line.

Finally, we need to send the processed output to the user.

$output = str_replace("<b>", "<strong>", $output);
$output = str_replace("<i>", "<em>", $output);
$output = str_replace("</b>", "</strong>", $output);
$output = str_replace("</i>", "</em>", $output);
echo $output;

At this stage, the code sent to the user will have a valid Document Type Definition. All tags will be correctly closed whether using HTML or XHTML. All images will have alt attributes. If we're using XHTML, all tags and attributes will be lower case (as long as the attributes are quoted). All invalid opening and closing tags will have been encoded. All ampersands should be properly encoded. And for good measure, we've replaced all bold (<b>) and italic (<i>) tags with the proper <strong> and <em> tags.

If you put it all together, you get the following code to be included at the end of each script:

<?php

$output = ob_get_contents();
$output = trim($output);
ob_end_clean();
    
function process_attributes($text) {
    return preg_replace("/ ([a-z]+)=\"([^( |\")]*)\"/mie", "' ' . strtolower('$1') . '=\"' . stripslashes('$2') . '\"'", $text);
}

function encode_chars($text) {
    $text = str_replace("<", "&lt;", $text);

    $tag_list = '((\/?)(!DOCTYPE|!--|a(bbr|cronym|ddress|pplet|rea)?|b(ase(font)?|do|ig|lockquote|ody|r|utton)?|c(aption|enter|ite|(o(de|l(group)?)))|d(d|el|fn|i(r|v)|l|t)|em|f(ieldset|o(nt|rm)|rame(set)?)|h(1|2|3|4|5|6|ead|r|tml)|i(frame|mg|n(put|s)|sindex)?|kbd|l(abel|egend|i(nk)?)|m(ap|e(nu|ta))|no(frames|script)|o(bject|l|pt(group|ion))|p(aram|re)?|q|s(amp|cript|elect|mall|pan|t(r(ike|ong)|yle)|u(b|p))|t(able|body|d|extarea|foot|h|itle|r|t)|u(l)?|var)([^>]*))';

    $text = preg_replace("/(&lt;)" . $tag_list . "(>)/mi", "<$2>", $text);
    $text = preg_replace("/(>[^<]*)>/mi", "$1&gt;", $text);
    $text = str_replace("/>", ">", $text);

    return $text;
}

if ((strpos($output, "<!DOCTYPE") > strpos($output, "<html")) or (strpos($output, "<!DOCTYPE") === false)) {
    $output = str_replace('<html', "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"http://www.w3.org/TR/html4/loose.dtd\">\n<html", $output);
}

$output = encode_chars($output);
$output = preg_replace("/<img([^>]*)alt=([^>]*)>/im", "<img$1`alt=$2>", $output);
$output = preg_replace("/<img([^`|>]*)>/im", "<img alt=\" \"$1>", $output);
$output = preg_replace("/<img([^>]*)`alt=([^>]*)>/im", "<img$1alt=$2>", $output);

if (strpos($output, "//W3C//DTD XHTML") !== false) {
    $output = preg_replace("/<(img|hr|meta|link|br|base|frame|input)([^>]*)>/mi", "<$1$2 />", $output);
    $output = preg_replace("/<(\/?)([a-z]+)( |>)/mie", "'<$1' . strtolower('$2') . '$3'", $output);
    $output = preg_replace("/<([^>]+)>/mie", "'<'.process_attributes(stripslashes('$1')).'>'", $output);
    $output = preg_replace("/&(?!#?[xX]?(?:[0-9a-fA-F]+|\w{1,8});)/i", "&", $output);
}

$output = str_replace("<b>", "<strong>", $output);
$output = str_replace("<i>", "<em>", $output);
$output = str_replace("</b>", "</strong>", $output);
$output = str_replace("</i>", "</em>", $output);
echo $output;

?>

CSS allows you to seperate your design from your markup, making maintenance infinitely easier, and your site more likely to work in different devices, both of which are definite pluses. It also, however, allows you to tell a page to display a different way depending upon what device is being used to render it.

This is achieved using the "media" attribute of the "<link>" or "<style>" tags, like so:

There are several media types available to you - [i]all, aural, braille, handheld, print, projection, screen, tty, tv[/i] - and a [url=http://www.w3.org/TR/1998/PR-CSS2-19980324/media.html#media-types]list of available media types with more detail[/url] is available from W3C (where you can find out more about media groups, as well).

With such a range of options, you can, if you like, create one HTML document that will display exactly as you like depending entirely upon which device is being used to view it. You can hide large images from PDAs, you can specify seperate font styling for overhead projectors - you can write your site so that it works well with the technology at the user's disposal. And one very useful side effect of this is that you can specify an entire print style without the need for copies of every page of your content, like the following, that will use the "normal.css" style sheet for screens, and the "printer.css" style sheet when printing.

For print styling, there are a lot of factors to consider. Are many users going to want to print out your header? No. But do you want your logo on the page? Yes. Is the navigation worth printing? No. Each item on a web page serves a purpose, and on paper, that may not be worth much.

It is best, then, to start at the beginning. With an unstyled HTML document. Pick a page to start working on, and remove all styles from it. With an unformatted page in front of you, it should be pretty easy to see what needs styling and how, but don't rush in. There's a lot to think about.

Fonts

Fonts are very different on the web to print. Sans-serif fonts are, allegedly, the best to use on the web. Serif fonts are, apparently, better on paper. So first things first, set your font to a serif font you like (personally, I like Georgia for Windows). As with picking all fonts, make sure you provide alternatives for those without the first-choice font.

Font sizing is a bit different on paper too. It's usually best just to leave this to the default, but if you want to specify a font, make sure you run plenty of tests to make sure it's easily legible.

Links

Links are not going to be a lot of use on paper, by their very nature. But that does not make them useless.

The above, if added to a printer style sheet, will make all links black and underlined, and add the address of the link in brackets afterwards, meaning that if a user did want to visit any site linked to from that page at a later date, they can.

Spacing

In print, margins and spacings are as important as with the web. There is no harm in adding in a little space between words and lines, and a decent gap around the edges, if it will make a print-version easier to read.

Hide Useless Stuff

You can hide elements in this style sheet easily enough, using display none. This will save some space on the paper, and reduce useless junk on the page, something the user will be very grateful for. Elements worth hiding are usually form elements, some images, marquees, and flash content. If you are unsure, print the page and then work through that page deciding what is useful and what is not.

Colours

Print colours will show up very differently to screen colours, especially as a high proportion still have black and white printers. Even those who don't will be grateful to you if you keep the proportion of colour to a minimum, simply because of the expense.

Highlight and emphasize things using italics, underlining, boldness and size in your print style sheet. Remove all references to colours where you can, save to set colours to black.

Page Address

You may want to add the address of the page itself to the page, and hide it, except when the page is printed, so that the user can return to your page later if they wish.

Tell the User

A user may see a page without a "printer friendly" link and print anyway, but they may be put off. Try and add a note to your page explaining that the page they are now viewing is printer friendly, and encouraging them to print it.

Finally

Do plenty of testing and reading. The print industry has been around a very very long time, and there are plenty of resources around for you to research what makes a document easy to read on paper as opposed to screen - make use of them. The more you test, too, the more likely you will be to notice small flaws in the print version of your site, in the same way that looking at your site during the design process highlights tiny imperfections that make all the difference once fixed.

Wish these simple measures, you should now be able to create an alternative version of your entire site, that will be invisible to the user until they actually print a page. They do not need to do anything bar click the print button.