Carpe Jugular Webmaster Resource » HTML and CSS

CSS Basic Page Structure

John Foulds — Sat, 05 May 2007 22:50:11 +0000

The concept of separating content from layout instructions was developed by document storage specialists decades before CSS came along. It is a logical concept which works best if approached logically. In the case of site design, that surely begins with basic page structure.

The first step towards having CSS behave predictably is to include a valid doctype and HTML tag as the first two lines of your HTML. A longer list of all the options is offered by W3C, but the most common are:

If you are coding in HTML:


...

If you are coding in XHTML:


...

If you don’t use a doctype, use one which is incomplete or doesn’t match the rest of your code, browsers drop into what is know as “quirks mode” which means they assume you have written very old code. They will ignore recent additions to CSS and interpret others wrongly. This can totally destroy your layout.

A major pitfall when using CSS is the unwillingness of browser developers to adopt a consistent standard. There are solutions (hacks) to almost all these inconsistencies, but it is easier to avoid them where possible. To this end I recommend beginning every CSS file with some parameters for the whole page.

body {
	margin: 0;
	padding: 0;
	}

These two properties define the space around the outside of an element (margin) and the space inside an element (padding). If we seem to be leaving logic behind already, think of the screen as the master container and the body (your HTML) as an element within it. It is necessary to set the padding to zero to counter the default padding set by Opera.

If you do want space around your design, just change the values for margin. You can either set a single value to be applied on all sides:

body {
	margin: 10px;
	padding: 0;
	}

or different values for top, bottom and each side:

body {
	/* top, right, bottom, left */
	margin: 20px 50px 20px 50px;
	padding: 0;
	}

Single Columns

It isn’t necessary to create an overall division to contain the rest of your page, if the whole page is a single column. Nevertheless, something like this means you establish parameters for your page which don’t then need to be repeated several times:

/* in your CSS file */
#wrapper {
	width: 780px;
	/* "auto" will center the block */
	margin: 0 auto 0 auto;
	padding: 20px;
	}
	
	
/* your HTML */

	All your content goes here

You can leave out the margin parameter if you want your content to show against the left of the screen. The padding parameter is also optional and of course the actual dimensions are up to you. Padding may not be useful if your content will appear on your overall background color, but if they are not the same, you probably would not want your content hard up against the edges of that center block:

Double Columns

I am going to use a double column layout to illustrate a complete typical page structure of header, content and footer:












	
		HEADER
	

	
		LEFT COLUMN
		RIGHT COLUMN
	

	
		FOOTER

Although we haven’t applied any styling yet to the header or content blocks, it makes sense to provide place-holders, since we have created the blocks in HTML. Making the total width of the left and right columns (350+350=700) less than the width of our “master” block (780-20-20=740), creates the space between the two columns. Note that otherwise no widths have been specified and 100% is implied by default. The float parameter, is what tells each block to place itself to the left or the right.

We haven’t styled the footer block but we did need to include clear: both. Without that parameter, the block would locate itself as high up the screen as possible, which in this case would be between the left and right blocks. Always include clear: both in a block which follows multiple to tell browsers to create it below the longest of the blocks above.

That covers basic page layout for one- and two-column designs. Three-column layouts are slightly more tricky, so I shall cover them separately.

HINT: It is a big timesaver to store code similar to that above as templates for all the basic layouts you commonly use: simply open a file and your page is already part made. I include a little more than shown above – basic fonts, header sizes, link treatment, etc – but only such elements as are always, or almost always used. Indenting code (and I usually leave an empty line between blocks) makes the flow of the code easier to follow, and if you indent every new block and close indents at the end, you will soon see (when your final block close instruction is away from the left of the screen) if you forgot to close a block along the way. Give ID’s and classes descriptive names so that your style file doesn’t become gibberish. Finally, always comment anything in your HTML or CSS which needed special treatment or might otherwise catch you out if you don’t look at the file(s) again for a year.

Update

At the beginning of this article, I mentioned the value of including parameters in a style sheet to account for the differences between browser defaults. For those who are more familiar with the issues involved, here is the set of instructions which I use myself. It pretty much over-rides all the default styling in all the major browsers, leaving you to start with a clean sheet, as it were:

/* clear browser defaults */
body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,fieldset,input,textarea,p,blockquote,th,td{margin:0;padding:0;}
abbr,acronym,fieldset,img{border:0;}
address,caption,cite,code,dfn,h1,h2,h3,h4,h5,h6,th,var{font-size:100%;font-style:normal;font-weight:normal;}
caption,th{text-align:left;}
div{overflow:hidden;}
h1,h2,h3,h4,li{white-space:nowrap;overflow:hidden;}
ol,ul{list-style:none;}
/* global hacks */
body{text-align:center;}

TGP Makeover

John Foulds — Fri, 20 Apr 2007 16:26:24 +0000

This exercise illustrates how to approach the job of converting a typical thumb-preview TGP page into table-less XHTML with all the styling being done in CSS. The original (this is just a sample including the main elements only once) is coded in HTML, uses tables and some CSS and this is the end product. Compare the source code from these two links, just note that to make this exercise easier to follow, the styles are included in the documents. In use they might be stored separately and referenced by .

The first step in a “makeover” like this should be to validate the document in its present form. This one had only a few errors:

Two title tags.
Character-set meta tag appears twice.
The header image has no alt tag.
In the full version of the original, a div id (largelinks) was used multiple times. ID’s must be unique: use “class” where a style is going to be repeated.

Although not directly related to this exercise, I changed the document’s character set to UTF-8 (Unicode). I don’t want to go off at a lengthy tangent (you can read more about Unicode here), enough to say that ASCII, Latin 1 (ISO 8859-1), etc., are deprecated these days. Use this instead (note the space and oblique used to close the tag):

Another change I made not directly related to the main point of this exercise, was to remove the bookmark javascript script into its own file, because it is search engine friendly to keep your head section to a minimum. That is one reason for creating a separate stylesheet file, the other being that if it is read in separately, the file will be cached, which makes subsequent pages of multipage sites load faster.

The value of converting to XHTML as part of a makeover is debatable. XHTML fans argue that you are future-proofing your work and since CSS behaves slightly differently, why be forced to learn these differences later and perhaps have to change some of your code? My view is that several scripts these days (notably blogs) default to XHTML, thus whatever the future may hold, it is easier to tackle a single HTML/CSS combo for everything. Fortunately, very few coding changes are required for XHTML:

Change your doctype and html tag to:
Here is an in-depth discussion of doctypes.
All tags must be in lower case. I changed the case of the keyword and description metas and also applied the space+oblique to close the tags properly (compare the two source codes). I also had to convert the p (paragraph) tags to lower case.
The target tag in the head must also be closed with space+oblique (be aware this tag works but is not part of the XHTML convention).
Search and replace all
tags making them
.
Change all image tags to end with that space+oblique.
All dimensions and tag parameters must be enclosed in quotation marks.
Although some HTML editors allow it, putting actual symbols (such as the copyright mark) into your code is a no-no because they may not display correctly (the copyright symbol of the original showed as a question mark in my browser). Use entities instead such as & for ampersand: this page at Pemberley includes an entity table.

Now the CSS. Here is the new file with comments:

/* 18sweeties */
/* There may be nothing in a style file to remind you to what it
belongs, so give it a title */

/* Some will tell you to lay out your CSS file strictly separating structure and fonts/colors. That can be very confusing for CSS novices, so here I have placed the page-wide parameters first and the rest in page order */

/* globals */
body {
	/* for cross-browser compatibility always state the overall margin */
	margin: 0; 
	 /* include MAC fonts */
	font: 16px Verdana, Geneva, Arial, Helvetica, sans-serif;
	background: #fffee8;
	color: #000; /* set a font color to be safe */
	}
img {
	/* use this and you don't need border="0" in any of your image tags */
	border: 0; 
	}
a {
	font-weight: bold;
	/* when colors are represented by 3 pairs, 0000ff, they can be shortened */
	color: #00f;
	text-decoration: underline;
	}
a:hover {
	/* it is not necessary to repeat parameters which will be inherited so only a color change is needed here*/
	color: #5454ff; 
	}
	
/* I always include this fix for a problem Explorer has with short divs. It is sometimes necessary to name the div, but this avoids that a lot of the time and if it isn't needed, (usually) doesn't hurt */
* html div {
	height: 1%;
	}
	
/* in page order for ease */
/* div align=center was used in the original document but is not compliant with current standards so this div was used instead */
#header {
	/* 17px represents top/bottom and auto left/right. There is no need to specify all four measurements when the pairs are the same */
	margin: 17px auto;
	text-align: center;
	}
.wrapper {
	width: 769px;
	margin: 0 auto;
	/* no need to specify left, top, etc borders when all are the same */
	border: #c103ff 2px solid; 
	background: #f9e6ff;
	}
/* check out the source code: all that was needed to replace the table holding the thumbs was a width-restricted container (wrapper, above) and a margin around the images */
.thumbtable img {
	/* replaces the cell-padding used in the original file */
	margin: 2px; 
	/* placing image dimensions here means no need to include them in HTML */
	width: 120px;
	height: 160px;
	}
/* when different style class have the same parameters, save code by combining them in a comma-separated list */
a:link img, a:visited img { 
	border: #cc0033 2px solid;
	}
a:hover img, a:active img {
	border: #cc0033 2px dashed;
	}
/* technically we could have given a class to the paragraph tag used originally but using a div here is more semantically correct */
.bookmark { 
	margin: 15px auto;
	text-align: center;
	}
.largelinks {
	font: 16px Arial, Helverica, sans-serif;
	font-weight: bold;
	letter-spacing: -1px;
	}
.largelinks a {
	font-size: 24px;
	color: #ed145b;
	line-height: 28px;
	}
.largelinks a:hover {
	color: #00497e
	}
/* lists such as trade links need not be displayed vertically and can be given specific widths */
ul.largelinks {
  	width: 769px;
  	margin: 15px auto;
  	padding: 0;
	list-style: none;
	}
ul.largelinks li {
  	float: left;
  	width: 33%;
  	margin: 0;
  	padding: 0;
	text-align: center;
	}
/* these next lines cleaned up a mix of paragraph tags and spaces */
/* after multiple columns, in this case the inline list displaying trade links you must tell browsers when you want to begin a new block or they will try to create an extra column */
#footer {
	clear: both; /* that is what this line does */
	text-align: center;
	padding: 50px 0;
	}
/* Mozilla browsers and Explorer do not handle "clear" the same way, so we end up with more space than we want in Explorer. The following instruction which can only be read by Explorer and is ignored by Firefox etc., corrects that */
*html #footer {
	padding: 35px 0;
	}
#footer img {
	margin-top: 50px;
	}

The result looks the same in both Explorer and Firefox and just as it did originally. The combined size of the HTML and (uncommented) CSS for the revised version is 5.01KB compared to 6.54KB for the same section in its original form. That is almost a 25% saving, providing obvious speed and bandwidth benefits. Perhaps more importantly, had this been a text-based site, the content to code ratio would have improved dramatically, giving a distinct edge with the search engines.

Troubleshooting CSS

John Foulds — Sat, 14 Apr 2007 12:48:58 +0000

If you are fairly new to CSS (and sometimes even when you are experienced) you are going to be faced with a page which just doesn’t look the way that you expected. Or perhaps it looks fine in one browser but not in another. Certain things are handled differently by the various browsers, but don’t be in too much of a hurry to assume that is what is going on: there really are not too many areas which require “hacks”. As in building a page, a methodical approach is what you need for problem solving whenever the answer isn’t immediately obvious.

Validate your HTML and your CSS. These validation services may spot your problem(s) for you, but in any case, attempting to solve visible problems will be much harder if hidden problems exist.
You may not see the results of changes (because of cacheing), so while troubleshooting, revert to placing your CSS in the section of your page. Just be sure to remember to creare an external style sheet again once your problems are resolved.
Always troubleshoot (and test while building) with an advanced/compliant browser such as FireFox. It is far easier to hack, if necessary, to make CSS work for Explorer than to fix your broken code for a broken browser and then almost certainly have problems as soon as you do test in other browsers.
Give all your main structural elements (different) colored backgrounds, to help you spot gaps, overlaps, and just plain wrong positioning. If you still have problems, give apply colored backgrounds to all the elements in the problem area(s) and look for stray padding or margins.
Make sure you aren’t including images or unbroken text which is wider than the block within which it/they appear/s.
Don’t assume the problem is related to the code in the area where the problem seems to be on-screen. Comment out half your style-sheet at a time (/* at the beginning, */ at the end) to isolate which half is causing the problem. Then within the problem half, comment out sections of the styling until you isolate which is/are the culprits.
If a troublesome element includes something like margins or padding, apply some really big values, to be sure they are being picked up at all.
Browsers can do strange things with measurements, so try reducing your widths. Instead of columns totalling 100% of the available width, reduce one or more so they total only 99% or even 98%.
Identify a block around the troubled area which itself appears to be behaving and comment out (in your HTML) all the child elements within it. Then uncomment them one at a time until the problem reappears.
Add margin: 0; to all the elements in the troubled area. If that fixes the problem and you want to clean up your code, remove the new settings one at a time, watching for the error to return. That/those you do not want to remove!

Avoid trouble!

I know we think, read and write linearly, but if you want to avoid unnecessary troubleshooting headaches, don’t code your pages that way.

Begin by coding the broad structure of your page (using colored backgrounds). Test. Then add the detailed but still only structural elements. If you need some text to identify or stretch an element, add just a few lines that emulate the real content: do not fill your page with content at this point, because it just obscures the details you need to see during debugging.
As noted above, always test first in a standards-aware browser and when everything is okay, then add any hacks needed to accomodate Explorer. But if you can code in a way which minimises the need for hacks, so much the better.
Be careful when pasting a block of code from one file to another. Saving snippets of code which you use frequently can be a great timesaver, but if they can be acted upon by something else on the page, they can be a source of problems.
Some hacks use javascript. Check what your page will look like to visitors who do not have javascript enabled.
Floats can be a thorough pain in the *ss. If your floats are showing up in the wrong place, margins haywire or the content within is doing strange things, the answer might be here.
Margins, in particular bottom margins, simply vanish. If you cannot apply a border (which resolves this problem) padding might be a better option.
BUT unless you are willing to do some math and apply hacks, avoid borders and padding with fixed-width elements, because Explorer really screws up the way that combination is handled. There are workarounds. It is almost always better to add padding to parent elements than to child elements.
Never include code you don’t really need.
Set element margins to 0 (unless specific values are needed) to allow for browser differences.
Zero values and line-heights do not need units of measurement, otherwise all none-zero values must be qualified by %, em, px, or pt.
Browsers are case-sensitive, so if you refer to a class as leftcol in HTML it must not be leftCol in CSS.
If you are using floats and want to avoid your content sometimes disappearing entirely or formatting unpredictably in Explorer, you should read up on The Peekaboo and Escaping Floats bugs.
Be aware there are (mainly Explorer-specific) extensions which don’t work at all in other browsers (validation normally points these up).
TEST every step of the way: it is far easier than trying to isolate problems in a complete page.

Why Validate?

Checking your HTML and CSS is a lot like spell-checking a letter or email. The difference is that as long as your pages look okay, you may be the only person who knows whether your code is valid or not. You are certainly likely to be the only person who cares.

You could argue that writing invalid code is like a mechanic not tightening a nut to the correct torque. Either you do a fully professional job or you do not. There are occasions when it is necessary to deliberately write invalid code – for example to workaround browser incompatibilities – but that is not the same as simply making mistakes. From the purely practical point of view, although many mistakes will stay harmless, some have the potential, when combined with something you may add to your page later, to break the page. It also seems illogical to complain about lack of common standards and then ignore the standards which exist.

CSS Boxes

John Foulds — Tue, 03 Apr 2007 04:16:35 +0000

Here’s some simple CSS and HTML, just a square box with some padding to keep the text away from the edge, a border for decoration, and then a margin to space it from the box next-door.



	top left

next

But look at these two illustrations. The top pair shows how IE6 interprets the code and the lower one how Firefox sees it.

Both handle the margin correctly, leaving 30 pixels between the two boxes. The difference is that Mozilla browsers ADD the padding and border to the height and width of the box, while Explorer INCLUDES their dimensions within the height and width settings. Thus the box which Explorer shows 200 pixels square displays as 260 pixels square in Firefox (200px + 20px*2 padding + 10px*2 border = 260px).

The solution is to place this piece of code, which is in a format Explorer cannot read but Mozilla browsers can, after the CSS for #example, thus:

html>body #example {
	width: 140px; /* desired width - 2*padding - 2*border */
	height: 140px;
	}

Et voilà, the boxes now appear the same in both browsers. This bit of hackery will come in useful whenever such differences rear their heads.

Update

The purpose of this article was to explain something you might experience and to provide a direct workaround. It is a better plan to avoid such problems in the first place:

For vertical spacing, margin-top performs fairly consistently but margin-bottom less so, since margins underneath blocks may be collapsed into the margin above the following block. You will suffer less grief if you try to stick with margin-top or with padding.

IE6 does several strange things when you combine floats with margins. Try to use widths and float directions in a way which makes it possible to avoid margins. For example, if two columns 500 pixels and 200 pixels wide are floated left and right within a 720 pixel block, a 20 pixel space will be created between them with no need for a margin declaration.

Although it involves a little more thought and typing, nested blocks often make for more certain cross-browser compatibility. A block 400 pixels wide, given a margin of 20 pixels and set inside an outer block of 440 pixels, will appear as you intend in any browser, more reliably than giving the 440 pixel block padding of 20 pixels.

Image Alignment

John Foulds — Sat, 31 Mar 2007 02:33:36 +0000

By default, images in WordPress posts are justified left, with text following (in a new paragraph) underneath. Which is fine a lot of the time, but obviously there are occasions when you would like to center an image, perhaps with text underneath, wrap text around the image or do that together with aligning the image to the right.

No problem, the HTML and CSS for all these requirements are quite simple:

HTML:
Pendle Hill
Pendle Hill
Pendle Hill

CSS:
.centered {
	text-align: center;
	}
.centered img {
	display: block;
	margin: 0 auto 5px auto;
	}
.alignright img {
	padding: 4px;
	margin: 0 0 2px 7px;
	display: inline;
	float: right;
	}
.alignleft img {
	padding: 4px;
	margin: 0 7px 2px 0;
	display: inline;
	float: left;
	}

Unfortunately, the illustration showing how well this all works only applies to Explorer. The result in Mozilla browsers, such as Firefox and Netscape, is somewhat different:

This mess happens because floated entities (see float:left; & float:right; in the CSS code) are supposed to be able to expand beyond their container. They are, after all, “floating”, ie not tethered to a container. Although the result in this instance looks horrible in fully-compliant browsers, such browsers are actually handling the parameter correctly.

All very interesting, but right now we want to know how to block this behaviour, and fortunately someone discovered this hack. Just add this code to the CSS above, and Mozilla browsers will show the same as Explorer:

.alignright:after, .alignleft:after {
	content: ".";
	display: block;
	line-height: 1px;
	font-size: 1px;
	clear: both;
	}

BTW I have added borders here to clarify the illustration, but they are not necessary to the structure, therefore I have omitted their codes to keep the example clean.

Update

Whenever you float blocks alongside each other, within a holding block, the problem illustrated above is likely to occur. Sometimes it is enough to add a clear:both; to the styling of the next block, but a consistent approach more quickly becomes instinctive.
/* add this to every css file that you use */
.clearfix:after,.clear{content:".";display:block;height:0;line-height:0;clear:both;visibility:hidden;}

Now you have two options which will always be available without further preparation:


	content
	content


or


	content
	content
	

CSS and the Humble List

John Foulds — Tue, 27 Mar 2007 17:14:36 +0000

We are all familiar with standard ordered and unordered lists:

But there is a whole lot more which can be done with them. For example, if you want to replace the regular symbols with an image, you can get much more consistent and controllable results by using a background image than with list-style-image:

CSS:
.navlist {
	margin-left: 0;
	padding-left: 0;
	list-style: none;
}
.navlist li {
	padding-left: 16px;
	background: url(files/redarrow.png) left center no-repeat;
}

HTML:

Item one
Item two
Item three

But with the exact same HTML, we could also produce these three-dimensional rollover buttons:

.navlist {
	background: #732BB0;
	padding: 2px 4px;
	margin: 0;
	width: 180px;
	font: 12px Verdana, sans-serif;
	}
.navlist li {
	list-style: none;
	margin: 0;
	}
.navlist a {
	display: block;
	color: #FFF;
	text-decoration: none;
	margin: 4px 0;
	background: #CC3399;
	border-width: 1px 1px 1px 8px;
	border-style: solid;
	border-color: #E085C2 #732BB0 #732BB0 #AFCE26;
	padding: 4px 6px 4px 12px;
	/* for IE */
	width: 99%;
	}
html>body .navlist a {
	/* hack for Mozilla browsers */
	width: auto;
	}
.navlist a:active, .navlist a:hover {
	background: #A4297B;
	border-color: #732BB0 #E085C2 #E085C2 #AFCE26;
	}

Another change of CSS, but still the same HTML, and instead of vertical navigation, we have horizontal:

.navlist {
	margin: 0;
	padding: 0;
	font: 12px Verdana, sans-serif;
.	}
.navlist li {
	display: inline;
	list-style: none;
	margin: 0;
	}
.navlist a {
	color: #FFF;
	text-decoration: none;
	margin: 4px 0;
	background: #CC3399;
	border-width: 1px;
	border-style: solid;
	border-color: #E085C2 #732BB0 #732BB0 #E085C2;
	padding: 4px 6px;
	}
.navlist a:active, .navlist a:hover {
	background: #A4297B;
	border-color: #732BB0 #E085C2 #E085C2 #732BB0;
	}

To turn this into a full-width navigation bar, does require a small HTML change, namely, wrapping the list into a div, plus a few more CSS changes:

CSS:
.navlist {
	margin: 0;
	padding: 10px 4px;
	font: 12px Verdana, sans-serif;
	width: 100%;
	background: #732BB0;
	}
.navlist ul {
	margin: 0;
	padding: 0;
	}
.navlist ul li {
	display: inline;
	list-style: none;
	margin: 0;
	}
.navlist ul li a {
	color: #FFF;
	text-decoration: none;
	margin: 4px 0;
	background: #CC3399;
	border-width: 1px;
	border-style: solid;
	border-color: #E085C2 #732BB0 #732BB0 #E085C2;
	padding: 4px 6px;
	}
.navlist ul li a:active, .navlist ul li a:hover {
	background: #A4297B;
	border-color: #732BB0 #E085C2 #E085C2 #732BB0;
	}

HTML:


Item one
Item two
Item three

All of which, I hope, gives you some idea of the possibilities offered by the humble list. And believe me, this barely scratches the surface. Take a look at Listamatic for literally dozens more variants.

Why Tables are Bad

John Foulds — Wed, 21 Mar 2007 19:41:17 +0000

In 1997 David Siegel wrote a book called “Creating Killer Web Sites” in which he revealed many ways by which web designers could bend HTML to their will. Brilliant – and necessary – in their day, these tricks are 10 years old and within the context of such a fast-changing medium, that alone should tell you something. In practical terms, this dated approach to site coding mixes presentational code together with content in way which is no longer necessary:

A site’s pages are bigger, therefore slower loading and more expensive to deliver, because most, often all that code has to be included in every single one. The combination of HTML file plus stylesheet is invariably smaller than the original HTML, but the advantage doesn’t stop there. Stylesheets are cached and need be loaded only once to serve a multi-page site.
Site changes and redesigns involve more labor – and therefore cost – to the extent that many site operators live with poor or outdated designs.
Webmasters put a lot of effort into search engine optimization, yet many of the techniques are less effective than simply stripping out all the display formatting code to produce a higher content to code ratio.
With tables, it is much harder to maintain visual consistency throughout a site, but if you do not pay for the extra work needed to ensure that, your site will be less user-friendly and cost you sales.
Table-based pages are less accessible, not only to visitors with disabilities, but also to the increasing number of people using cell-phones and PDA’s to browse the web.

Of course no-one wants to go back to school when it is easy to keep doing things the way you already understand. Why spend a few days learning something new instead of getting right to work each morning on projects which will earn money? The answer is that using HTML for both styling and content is costing you money, each and every day you resist the change.

Zen Garden is an amazing site for showing how CSS alone – with no changes at all to the underlying HTML – can transform the way a site is displayed. But what practical value is there in that virtue?

It means that at best you can totally change the appearance of your whole site by making changes to just one file, and at worst that and some new graphics. You don’t need to touch the HTML (which should be a major job if your site has the depth which search engines like).
Which in turn means you could afford to change your design frequently if you feel it worthwhile. You could drop in seasonal designs cheaply and easily. If you have gone for a magazine-style format as some adult sites have in their member areas, it would take only minutes to change your color scheme to reflect the current magazine. You could even offer a variety of designs via a style switcher.
You have the opportunity, not only to improve your content to code ratio, but to lay out your HTML in a way which brings your content to the top of your files. With search engines that do not spider whole pages, the advantage is obvious, but that structure also makes your pages more accessible to people visiting your site with non-graphical viewers.

Blogs & CSS

I’m not naturally an evangelist for geekdom. This article was prompted by the number of people claiming to be adult blog designers, of whom not a single one was producing table-less design. Nine months after the original article, valid themes are still the exception.

Which is ridiculous, because blogging software hands its users an automated way to produce modern, user-friendly, search engine-friendly, webmaster-friendly code. Most such software even provides one or two themes, posts, comments, links and templates to show how it all hangs together. All of which is enough to allow hundreds of mainstream designers, amateurs as well as professionals, to stay true to that model and get the maximum advantage from it. Yet the majority of adult designers immediately revert to using code from the 90′s. It is irrelevant that the sites may display as intended: especially when the appeal of blogs is their reputed attractiveness to search engines, it makes no sense to throw a big part of that appeal away through sloppy coding

Toplists via CSS

John Foulds — Mon, 12 Mar 2007 05:02:20 +0000

A very simple article today: a toplist courtesy of CSS.

The HTML is very straightforward. You want more or fewer columns, no problem and vertically you can use as few or as many links as you wish. Nor does it matter if there are the same number of links in each column.


  
    
      A Trade Link
      A Trade Link
      A Trade Link
      A Trade Link
      A Trade Link
    
  
  
    
      A Trade Link
      A Trade Link
      A Trade Link
      A Trade Link
      A Trade Link
    
  
  
    
      A Trade Link
      A Trade Link
      A Trade Link
      A Trade Link
      A Trade Link
    
  
  
    
      A Trade Link
      A Trade Link
      A Trade Link
      A Trade Link
      A Trade Link

There are a couple of potential pitfalls in the CSS. The first is that Firefox will not place the content which follows the toplist beneath it, unless you include the “hack” shown below. The second is that to avoid falling victim to Explorer’s buggy way of handling floats, the total width of the columns should never be more than 99% of the width of the containing div. Otherwise the CSS is also straightforward and can be customized to taste.

.toplist {
  /* if you want a margin above and below the toplist, replace the zero, thus */
  /* margin: 20px auto; */
  margin: 0 auto;
  /* the width may be fixed or a percentage */
  /*width: 99%; */
  width: 500px;
  }
/* Firefox hack */
/* keep this otherwise following content will appear alongside the toplist */
.toplist:after {
  content: ".";
  display: block;
  line-height: 1px;
  font-size: 1px;
  clear: both;
  }
.toplist ul {
  /* adjust the margin to suit */
  margin: 10px;
  padding: 0;
  list-style: none;
  /* text-alignment is left by default but can be changed */
  /* text-align: center; */
  }
.tl-column {
  /* IMPORTANT: the total width of the columns should be 98%-99% of the available width */
  width: 24.7%;
  float: left;
  }

Doctypes

John Foulds — Sat, 10 Mar 2007 04:44:28 +0000

Be warned, this is “here be dragons” territory…

To cope with both old (and badly written) code and well-formed up-to-date code, modern browsers have two modes: Quirks mode for dealing with the former, allowing non-compliant code to be displayed without (usually) too much ill effect, and Standards mode for displaying compliant documents according to current standards. There is a third mode called Almost Standards which is used by Mozilla, Safari and Opera 7.5 with certain doctypes and in this mode some vertical sizing is handled by pre-CSS2 standards. Standards mode in IE6 and older versions of Opera could really be called Almost Standards because these browsers do not comply fully with CSS2 anyway as regards vertical sizing. Towards the bottom of this page is a chart which explains the other differences between the behaviour of the various browsers according to mode.

XHTML documents are worth an aside to note that they really should not be delivered as mime-type text/html at all, but as application/xhtml_xml and when they are delivered that way, doctypes are redundant. Unfortunately, no-one using IE6 would then be able to read your pages at all, so when delivered as text/html, they get treated as regular HTML documents. That reality makes a nonsense of many of the claims made by XHTML evangelists.

Ironically, since the point of Document Type Declarations (doctypes) is to reduce the need for hacks, they are in themselves arguably hacks. Their job is to tell browsers according to which mode the documents they are reading should be interpreted. Hacks or not, they are vital because if you have coded for one doctype but fail to identify it correctly to your visitors’ browsers, your carefully crafted pages could end up looking very different from the way you intended.

All modern browsers use doctype sniffing (aka switching) and look to the very first line of an (X)HTML document for a doctype. You may put some php code (for example) that will be interpreted server side ahead of this declaration, but any code which will remain visible in the source, must follow the doctype. Fail to do that and all browsers will revert to quirks mode, ignoring any CSS2 coding you may have used.

Doctypes have two components. The first is compulsory, it is an identifier, much as the numbers attached to versions of PHP are. The second (optional) part is a URL pointing to a document which contains information and rules which apply to this identifier. The two components must be matched if you use both. You can leave the URL out, but – depending on the level of HTML you have coded for – doing so will cause some browsers to drop from Standards to Almost Standards or Quirks mode, even if you have declared a Strict doctype.

Oops. Another term to identify!

In the context of browsers, we talk about Quirks, Standards and Almost Standards modes. When we are dealing with HTML documents, the relevant terms are Strict and Transitional. When we declare that a document conforms to Strict standards, we are telling browsers to interpret it according to the latest (currently CSS2) standards. Any code which is non-CSS2 compliant will be ignored and if we attempt to validate a document which is declared as Strict which includes non-CSS2 compliant code, it will fail. A Transitional document will not fail validation only because it includes older code, modern browsers will (usually) recognize any CSS2 code which is included while also accomodating older code, and older browsers, providing they are not too old, will mostly feel right at home.

At first glance there are good reasons to declare a Transitional doctype, but Strict DTD’s do encourage the complete separation of structure and presentation which you must have in order to get the full benefit from CSS. And, as some people are about to learn with IE7 which is dropping support for the star html hack in Standards mode, you adopt non-compliant techniques at your own risk.

If you want to dig into this further, there is a detailed chart of browser behavior relative to doctypes here and W3C has a list of all the currently valid doctypes. These are the most relevant from which to make your choice:

HTML 4.01 – Strict, Transitional, Frameset

XHTML 1.0 – Strict, Transitional, Frameset

And I guess we now need an explanation of how to choose between plain old HTML and XHTML (extensible hypertext markup language). There are several potential advantages in using XHTML, primarily that it is easier to read and write than HTML and that the “extensible” part of the name refers to the ability to mix in other XML elements (from MathML for example). But because XHTML cannot be properly served up to some browsers (and not at all to IE6), XHTML ends up being treated by browsers exactly as if it were as regular HTML. Thus any advantages it has remain theoretical at the present time, except to authors working in very specific areas. Never use XHTML 1.1 because it is not fully compatible with HTML and if you have read further on your own and come across XML declarations for XHTML, be aware that prefacing an XHTML doctype with an XML declaration will force IE6 into Quirks mode, regardless of the doctype you use.

One parting note before I go take some aspirins, is that there are elements which are not valid for Strict doctypes. These include center, font, strike, u and – the one which might affect more webmasters – iframe, popular in the delivery of geo promos and live webcam promos. If you want Strict documents to validate, in place of iframes you should use objects:

Alternative text in case the iframe cannot be displayed

becomes

Alternative text in case the object cannot be displayed

There is a fairly long list of attributes which are also not permitted with Strict doctypes. That list can be found here and the one many will want to be aware of is that the target tag is among the no-no’s. To use target and still validate, this piece of javascript will solve the problem.

Although browsers may read the URL you have included in your doctype, they are not required to do so. Since the treatment of entities such as   is defined in that DTD, it is therefore safer to use the numeric equivalents in your code. A full list is here.

Flexible SE Friendly TGP Layout

John Foulds — Wed, 07 Mar 2007 04:59:09 +0000

I jokingly made a suggestion to something who had just completed the conversion of a thumb-preview design to table-less. Namely, that he try to find a way of placing some text links, as a bit of SE bait, high in his HTML, but have them appear low on the page as he would obviously want for such a site.

And it actually can be done without too much difficulty, although oddly it is trickier to achieve that effect with a single-column design, than with two- or three-column layouts. But it involves the use of absolute positioning.

At first glance, absolute positioning is a designer’s dream. You can place all the components of a page with pixel-perfect precision. Providing you know exactly how big each block is, and the use of text if at all, is limited, absolute positioning works well. But TGP’s may get an extra-long description which wraps onto the next line and as soon as something like that happens, that perfect design can be spoiled. Worse, Firefox users, even when you have set what you might believe – pts for example – is an absolute font size, can wreck such a design just by rolling their mouse wheel to make the text on your page bigger.

So what we have here is a page which, instead of fearing that possibility, exploits it. At the same time, it is a hybrid thumb-preview plus text layout which attempts to be reasonably search-engine friendly. In deference to a suggestion from another visitor, this page is coded in HTML 4.01 Strict.

The first thing to notice is that if you hold down your control key while rolling the wheel on your mouse, you can make the text bigger or smaller. It doesn’t degrade as well if you decrease the font-size in Explorer, because a single click has twice the effect it would in Firefox. However it deals with larger fonts equally well in both. What might also catch your eye is that the thumbnails themselves also get larger or smaller. Not only do the horizontal dimensions change, but text and images remain aligned vertically too (until very small sizes force word-wrapping).

The main purpose of making this layout in this way was to enable flexible sizing in Explorer the way that Firefox allows, because it isn’t only a way surfers can mess up your pages. Used positively, it is a way to make your pages more user-friendly for a wider variety of monitor sizes and screen resolutions. Admittedly you can only allow image resizing if you have good quality images, and even then some distortion creeps in as the size moves too far from the original. But the payoff may be worth it against someone seeing only postage stamp sized thumbs at high resolutions.

You are welcome to hack the source about and for convenience I have left the styles in the HTML document. In action, you would save the styles into their own file and link to it as I have indicated.

Okay, to recap. What we have here is an attempt to make a thumb-preview page which is more search-engine friendly than usual, and a page which accomodates users’ font-size preferences. And bear in mind, to make this layout work in fixed sizes, it is only necessary to switch to pixel (px) dimensions to suit your own tastes, thumb sizes, etc.

Search Engine Friendly

I have annotated the usual meta tags – title, description and keywords – plus h1, h2, and h3 tags. When you are selecting your keyword phrases, bear in mind that almost one search in three is done on 2-word phrases. Another quarter of all search use three words. You might try for two such phrases in your title, adding two more in your description. Unless you are creative enough to write something new, it is reasonable to combine both your title and description for your h1 tag. Mix the keyword phrases up some for the h2 and h3 tags. And of course try to find a happy medium between fiercely competitive keyword combinations and ones which will rarely be used.

This layout – at least for a page with lots of images and links – is quite search engine friendly. Unless you do add a promo at the top (and even then it could be a text-rich promo), the HTML goes straight into h1 and h2 tags and then the text links to galleries. This is a very good thing because some search engines only read the first few hundred words of a page. BTW if they don’t find your keywords in the early part of your content, you could at worst be penalized for attempting keyword spamming.

I have suggested that for image alt tags you use the gallery description. Link title tags are a little more tricky, because they should not duplicate the alt tags or the text links. If you have sub-categories on your TGP, use them for link-titles, otherwise I would be inclined to leave link-title tags out. The general consensus appears to be that alt and link-title tags do not count much these days towards SE placement, so if they cannot be handled automatically – without the risk of spamming – they are probably best ignored. Most trade scripts allow you to include descriptions these days: you can choose between displaying them or, with your own keywords mixed in, use them as link-title tags in your toplist.

You should of course increase your site depth by adding archives, faqs, link pages, reviews, a site-map and anything else which is relevant and you have time for. And if you really have the patience, go through your gallery descriptions and make sure they are generously sprinkled through with your keyword phrases.

The CSS

As it should be with the presentation code removed, the HTML for this page is very simple and I don’t believe it needs any explanation. The CSS is also straightforward but some comments are in order

body {
	background: #FC0;
	font: 0.8em/1.8em Verdana, Geneva, sans-serif;
	}
#outer {
	margin: 0 auto;
	width: 70em;
	background: #FCE5FC;
	border-right: 0.3em solid #F6F;
	border-left: 0.3em solid #F6F;
	}
#header {
	background: url(files/article02301.gif) center 30px no-repeat;
	}		
#header h1 {
	font-size: 0.8em;
	font-weight: bold;
	text-align: center;
	height: 13em;
	min-height: 140px; /* min- and max-height do not work for IE6 */
	max-height: 155px;
	}

Before most of us ever heard of CSS, we were used to quoting image sizes in pixels. Perhaps because of that, but also because it is the best way of ensuring browser-independent identical sizing, we most commonly express dimensions for CSS in pixels (px). However, the purists don’t like that when it comes to font sizes and I agree with them. If you select an absolute font size – say 14px or 11pt – it may look great on your screen, but on a smaller one or a much bigger one? By declaring a relative font size – in this case em although % works as well – you are only modifying the font which your visitor is using by default (0.8em = 80%). The strength of this layout (and it is only a layout, not a design exercise), is that the whole page changes to suit. An “em” BTW is an old-school printing term for the space occupied by the capital letter “M”. Here the line which begins font: 0.8em/1.8em means that the page’s default font size will be 80% of the surfer’s default size and that the line height will be 1.8 times the height which would normally be applied to that size of font (I am a great believer in the liberal use of white space).

To not divert the search engines with a logo, it is inserted as a background image (note that when calling an image you NEVER put quote marks around the URL). By default a background image will begin at the top left and repeat, but you can position it anywhere you like and instruct it to show only once. Top, left, center, right, bottom – as well as pixels as used here – are all valid descriptors. This is the only place on the page I have reverted, partly, to the use of pixels, because the one thing you cannot do with a background image is declare its size. And if you cannot declare its size, you cannot change it. Which is also why – at least for those browsers which recognize them – I have used min- and max-height to restrain the font-size related expansion of the header.

.right {
	display: inline; /* required for Explorers double-margin bug */
	width: 43.8em;
	float: right;
	line-height: 1px; /* prevents extra vertical spacing in Firefox */

Anyone who has been reading other articles here is going to be familiar with float. For those who are not, if you want two or more columns to appear side by side, you “float” them. Explorer however has an odd bug when you combine margins with floats: it doubles their size. Fortunately, the display: inline; statement takes care of that. The other “feature” dealt with in this part of the CSS is that when you flow a bunch of images into a div as we have done here, Firefox inserts a couple of extra pixels vertical spacing between the rows. Reducing the line-height to a very small dimension is the answer to that.

The only other item of note in this CSS is the use of clear: both; in the styling of every div which follows a multi-column section. Any of three things may happen if you leave that out: the first that the block may try to climb up the screen if the columns above have any space between them; the block may place itself at the end of the shortest block above or alongside the rightmost block; and if there is a background, as here, it may not extend all the way down the screen.

Oh sizing. If you want to convert pixels to em’s, the calculation is easy. More or less. Our default setting of 0.8em works out on my monitor as 13px, so if I want to translate a width of say 260px (pixels) into em’s, I simply divide by 13. Thus the images which in more traditional terms are originally 180×135 pixels, became 13.85×10.38em’s.

Verification

Both to avoid problems for you and your visitors and to maximize search-engine friendliness, you should verify your code. One unfortunate consequence of using a Strict doctype (see an earlier article here for explanations of doctypes) is that target=”_blank”, so beloved of TGP designers for cutting out duplicate code, is not allowed. There are three possible solutions. The first would be javascript, but not everyone has javascript enabled. The second would be to create a custom doctype, which browsers may or may not read. So I suggest that you get your code validated and once happy all is well, add the offending instruction to your page. That is not an elegant solution, but it is the most practical.

Try this at home!

Reading through this article to see if it needed revision, it occurred to me that there might be a way to achieve the commonly desired object of having text higher in the HTML but thumbs showing first on-screen, without needing to resort to absolute positioning and its potential headaches.

You would do something like this:
	link link link
	img img img
All quite normal, but the trick is to make the thumb block float left, while at the same time declaring its width to be the same as that of the holder. Float the text block right and it would be forced to appear below the thumbs…