Digital Waffle

Semi-Update.

Tue, 13 Apr 2004 17:18:00 GMT

I've moved all my articles to my new website Twilight Universe. They are there under Articles or 'Waffle."

I will continue to update here, but it will probably be more extract related, or maybe a feed type account, of the articles I'll put up on my main site. I'll decide in more concrete terms soon. Anyhow, thought I should let you all know.

PNG's Just Got Smaller.

Mon, 02 Feb 2004 19:47:36 GMT

This post won't make too much sence unless you've read this or thisentry where I discuss PNG files, and then amendments to a program resulting from my article.

However, now that is cleared up... moving on.

What's all this about then?

Since I wrote the article above the software has moved on. PhotoShop has moved onto another version (PhotoShop CS), VIMAS has updated Web Image Guru to v5, and Ken Silverman's updated PNGOut was released.

So what does this mean for the results I got for their previous versions?

Well a quick bit of testing should solve that question shouldn't it?

Results

Using the same UnionJack image as last time (which came out as 4.62 kb as a GIF) I loaded up the new software and tested things out, then tried to optimise them with PNGOut. The following is the results:

</tr><td>PNGOut(with new /c3 option)</td><td valign="top">3.10 KB (3,180)</td><td valign="top">2.90 KB (2,970)</td></tr>

	PhotoShop	Web Guru
Original	5.73 KB (5,870)	3.29 KB (3,373)
New Version	3.29 KB (3,373)	3.08 KB (3,163)
PNGOut	3.11 KB (3,192)	2.94 KB (3,011)

Notice the new PhotoShop size. They have greatly improved matters here, with their new Save For Web (powered by ImageReady code) performing as well as the old version of WebGuru. Compressing the image with PNGout only serves to reduce the photoshop image down to the smallest obtainable size that was reached with the second PS test in the last article. Not the smallest we could get it, but pretty good, and this does mean that they have solved the awful bugs that PS used to have.

Web Guru 5 performs extremely well, beating the final PNGOut version of the PhotoShop image right from the start. However.. there is an interesting point to make here. Previously WG claimed the image had 99 palette entries, as does PhotoShop currently. However in this new version it only finds 84 entries. Confusingly after comparing the images I could not find any difference in at a per-pixel level.. so this is something of a mystery to me, akin to the original PhotoShop bug of finding 130 entries.

Perhaps VIMAS has managed to optimise their colour analysis, or some other background process that I don't know about. Whatever they have done certainly these fewer entries will help their final size stay smaller, but seemingly it doesn't impact upon the actual image. I don't concider this anomaly to be very important, but I think it was worth mentioning. If anyone can shed any light on this, please tell me.

Compression with PNGOut on both images yeilded significant gains, with the newer /c3 option actually improving matters even more. Finally we can get the image to below 3000 bytes! A challenge I had made previously.

Conclusions

With its Creative Suite (CS) version PhotoShop has closed the gap its previously inept versions had left, and compression with PNGOut on its achieves excellent results, if not quite reaching the optimal. PhotoShop now is a platform that can be realistically concidered for working with PNG web images.

Web Guru however still manages to just stay ahead of PS, but its lead is much less than it was. PNGOut also gets excellent results with the new version, so this would still be my choice of software for now.

However now PhotoShop has caught up with the rest of the world there is absolutely no reason to use GIF for static images. PNG far surpasses it in every respect now, and the industry standard application produces good size files. Just remember that you could be saving over 1.7kb per image in the above example. Thats a lot of saved bandwidth, and a lot of saved money. Plus your pages will load faster, and provide a better user experience.

Its win, win really.

Packs O' Hacks

Fri, 30 Jan 2004 20:38:50 GMT

Today I'm going to talk about the dirty side of style sheets. Hacks.

Because of differing levels of browser support, and implementation, of CSS many designers prefer to serve different style sheets to browsers that can't handle them. These methods can also be used to serve different style sheets to different browsers but, because the reasons for doing this are minimal and subject to change with every minor browser revision, I won't cover them right now.

What I will cover is a way of making Livejournal more accessible to users, and a method of hiding CSS files from browsers that won't understand them properly.

Why Hacks? I Thought we were trying stop that?

We are, however we must be realistic. The differences in browsers still mean that some compensation for them is required. The advantage of hacks applied to style sheet is that, rather than a complicated HTML hack where the content of each page would be moved around and generally messed up, with no regard to other applications, a style sheet hack is easy to modify across a whole site by changing one file.

The wisdom here is that while hacks may exist.. they don't effect the portability or accessibility of a document if they are in style sheets rather than the html.

LiveJournal Hacking 101

In my last entry I mentioned that I'd had to hack one of LiveJournals layouts so that it was no longer a fixed pixel size in its text. The layout (Component) is an otherwise excellent one, but the its authors reaction to my query about this accessibilty problem was basically "It works in Mozilla, so I don't care."

However sad and short sighted I feel that is, not to mention the idiocy of designing for 4% of the viewing public, there is at least a way around this problem. Component is part of LiveJournal's S2 style system, while - unlike S1 - it doesn't allow direct editing of the HTML files that make up the page, it does allow advanced customisation.

to edit your layout go to Customise -> Advanced Customisations -> your layers -> Edit layer.
Then you should see a text box in which is all the settings for the layout, there is no need to change any of this (unless you want to), but at the bottom of the page paste the following:

function Page::print_custom_head() {
	"""
	<style media="screen" type="text/css">
	BODY { font-size: 69%; } 
	td, tr, select, .entry, .entryDate, .entryComments, .sideHeader, .compList { font-size: 1em; }
	</style>
	""";
}

This will insert a custom style declaration into the head of your document, and so override the previous style sheet settings, while keeping unaffected rules intact. A font size of 69% is the setting I use (approx 11px high at default settings), but you could use another size if you wish. Just experiment with a size you feel works for your layout. You can also any other style rule in here, I've used it to change the heading tags and subject style for example.

Cascading Style Sheet Hack

This next hack has a more general application. It is called a High Pass Style Filter. For this to work correctly you need to have a valid doctype, otherwise some browsers will not read it correctly. What this hack does is hide style rules from browsers that won't understand them, which is basically version 4 browsers and below.

Firstly, declare a style sheet as you normally would in the head of you document:

<link rel="stylesheet" href="highpassfilter.css" />

And then the "highpassfilter.css" file should contain:

@import "null?\"\{";
@import "highpass.css";

Where 'highpass.css' is your actual style sheet with all the rules you would normally apply. Also it is advised that you have a file in the same directory called 'null' - note that there is no file extension. This file should just contain a comment tag like so:

/* nothing to see here */

This way browsers won't be confused by a completely empty file. For example IE/Mac delay's the pages opening for at least 30 seconds if you don't have something in the null file. Older browsers are confused by the sequence '\"\{' and do not import the correct style sheet below that. For a more detailed explaination of how and why this works visit Tantek's site, as he is the one who originally documented this hack.

Nice and simple though huh? A very useful hack that can be applied to almost any situation.

I hope both these hacks will help you in some way, remember - its better to hack the style rather than the content.

Textual Intercourse

Tue, 20 Jan 2004 19:57:18 GMT

Following on from my previous article on typography on the web I thought I'd mention a bit more about how text displays online.

As a lot of you probably know, text is usually measured in points, be it 10pt, 12pt or 150pt... its the most common way you'll see text expressed. The reason it's like this is because text is usually going to be printed out, or archived for printing later. There is a problem with this however when working for the web.

You see a point doesn't mean anything on screen. Nothing. Why would it? The base measurement on screen is a pixel. Pixels are rectangular (usually square, but not always), and fonts are made from vector curves. There are complex algorithms and instructions (called hinting) that govern the way a font is displayed on screen, I won't go into all that here, but basically the software makes its best guess from these rules at how the font should look at a certain pixel size.

So what does this mean for the web? Well CSS allows us to use points, pixels, ems, and other measurments to define the size of a font. Points don't make any sense for the screen, so we shouldn't use them right? Ok.. so what else to use?

Pixels! I hear you cry. Thats the base screen unit, everything should be fine in pixels! Right? Right?

Certainly that's been the prevailing wisdom of many designers. Pixel based displays allow you to know exactly how text will display on screen. They give pixel perfect control to designers. They are fixed.

Sounds good huh? There is a problem though. Text shouldn't be a fixed size in a webpage. A webpage isn't a static display like a page, its a fluid flexible beast that changes depending on a users settings, their screen size, and window size.. and that's just if they are viewing it on a PC. Throw in different OS's, browsers, oh and remember that they could be viewing on a mobile phone, PDA, or some other device that hasn't even come on the market yet.. it all starts to look a bit more complex.

The goal of not using points is so that the text is rendered correctly, not so that the text is a fixed size. Granted in some case fixed sizes might be wanted, but for the most part they just add to the inflexibility, and illegibility of a design.

Pixel Perfect?

Specifiying font sizes in pixels does seem like a sensible option for screen media, however the problem here lies with the browsers, in in this case Internet Explorer. You can resize text by holding down Control and rotating your mouse wheel, unfortunatly this doesn't work in IE when text sizes are specified in pixels. When you specify a font size in pixels most other browsers will still let you resize the text, but IE doesn't. I have a sneaking suspicion that IE's behavior is actually correct, because else pixels sizes would be pointless. However because of its poor support of em units in the past this has been the only way to specify text effectivley on the web. So this 'correct' behaviour has led to accesability problems, and other browsers have acted to combat it by allowing it to be resized.

I even had to hack the layout of this journal (LiveJournal's otherwise pretty excellent Component scheme) to stop it using pixels.

Why all this extra work for something that you might not even notice? Well that's the point, you might not notice, but someone on a larger screen resolution, or who has trouble reading could very well notice, and have no option either if the font was in pixels.

But I Can Change My Default Size!

Yes, yes you can change the size text is normally displayed in your browsers. However this only applies to unstyled content. Any styled content will override this default. In the case of pixels you can't change this at all, but using any other method you could.

Some people might complain that the font size displays too small to them or, rarely, too large. These are people who have generally changed their default font size in the browser to something smaller than its normal setting (which is 16px, believe it or not). These people acted sensibly when confronted with older, badly coded, content, however this shouldn't be nessesary if more people adopt good practice. These people tend to complain that 'other sites don't have this problem.' This is correct, they don't because they are probably using pixels, however the problem doesn't lie with the sites, it lies with the users browser. Text is only displaying correctly when their settings are overidden, so where does the problem lie?

Generally most users who change this default setting will be doing so because they have a specific use for it, and quite often will have a specific style sheet to impliment anyway. The rule of thumb here is that by supporting correct practice you are making hacks like the one the small minority have done obsolete anyway.

But It Works Fine In Mozilla/Opera! Why Should I Care?

Correct, resizing text in Mozilla (and so Firebird) and Opera works. However these browsers are used by a huge minority of people. Internet Explorer accounts for well over 90% of traffic to websites. This means that there is a high probability that someone who would need to change your sites font size will be using it. Therefore, like it or not, its quirks need to be taken into account, and you'll be following Web Standards recomendations anyhow. Its a win win situation.

Designing for one browser is something that we are trying to get away from. Remember all those "looks best at 800x600" or "Best viewed in Netscape/IE" buttons from a few years back? That is how we got in the mess the web is in today. I certainly don't want to go back there.. do you?

Why Be Flexible?

The idea of creating a flexible design is something that isn't natural to a lot of designers, especially ones that come from print based design, and why would it be? A page is a static medium, it isn't able to be resized or its view settings changed.. and so it is fundamentally different to a web page. In fact calling it a page, at least in layout terms, is very wrong. This is why when dealing with CSS you refer to anything that will show up on a regular PC/Mac as "screen" - that's its media, the screen.. not the page.

The most basic example of where designing for a static medium like a page is a disadvantage is when the user views a web page at a higher resolution that the page was designed for. Pages that are not built to be flexible will 'break' and the layout will fall apart. Content may even become unreadable. Obviously this is a bad thing.

There are many other examples of where layouts can break, however we are dealing with text here, and text is one of them. Take the case of someone with poor sight. They will most likley have their default text size set larger in their browser to compensate. Now in a pixel sized layout their text will be the styled size, and be unchangeable if they are using IE. Even if it wasn't pixel based, if they change the size of the text then suddenly all this text will have to grow and fit in the box you have put it in.

Now this may not be a problem, but it often is. Say you have text in a box that is set to a fixed width of 300px and height of 200px, it could be a menu box perhaps, or just a little feature box. When the text is resized and won't fit into that box the box will break, and this could effect your layout depending on how you've coded it. It might not be just one box, but the whole layout that breaks.

Obviously this isn't what you want to happen to your work. In other words, when designing, avoid using pixels as a measure unless you know for certain that the measurment won't be effected should text or window sizes change. There are many times this is the case, you should however know for sure. Remember - a user can overide your styles totally should they want to, so its best to code flexibly in any case.

Textual Compatibility

So what sizes should you use? Well.. this is where the fun starts. IE, for some reasons known only to itself, used to have serious problems displaying a font at asize lower than 1.0em.. which is the large 16px default. So how do you code flexibly with this in mind?

Well thankfully all version of IE work if you specify the size of your text in em's but your BODY tag in a percentage. With this you are effectivly saying that a font is a certain em size, but IE thinks you are not. Don't ask me what is going on inside IE, but it can't be pretty.

So what sizes to use? Well for your content I would suggest starting that as 1em, that way everything is relative to the content size.. and you know how that will behave in your page. For the BODY tag you have to use a %.. now for reasons that basically come down to cross-compatibilty, and that they work out as equivilent to standard font sizes I recomend the following:

55% is equiv to 9px
60% is equiv to 10px
69% is equiv to 11px
76% is equiv to 12px

These are the most common sizes you will use, you shouldn't use anything smaller than 9px equiv, because that is about as small as a font can go and maintain legibility. Remember that this is accurate at the default font size, which most ppl haven't changed. Also remember that this is for your base size, not for anything else, that is handled with em's.

Example Style Sheet

The following illustrates how you might set up a style sheet using the above method.

BODY {
           font-size: 69% ;
           }

#content {
           font-size: 1em ;
            }

.title  {
           font-size 2em;
           }

As you can see, its very simple to implement, and has a real impact on the usability of your website. Hopefully I've covered enough in this article so that you can understand not just the method, but the reason for using it. If you have any questions, comments, or just want to discuss this, please comment below.

Notes and reminders...

Tue, 30 Sep 2003 00:59:12 GMT

No update this week as of yet.

Real life had gotten in the way of technique and education, so I thought I'd update you an a few things that you might not know about this place, or that I've added recently.

There's an XML feed of this site. Its listed in the links section of this journal, just up on the right side. I know many people like to use syndicated RSS feeds, and it happens to be a nice side effect of using LiveJournal that I get one. Feel free to add it to your news program, or spread it around. A bit of promotion is always nice.

You can contribute. This has always been true, if you fancy promoting a bit of knowledge, or talking about a subject that you feel is relevant, then e-mail me at digitalwaffle@livejournal.com with the subject you want to talk about. Quick and painless.

I may post up a completed article later in the week, but I have two to finish and lots of other work to do, so don't hold your breath. However I WILL post for sure next monday.

Till then, keep tuned, same bat-time, same bat-channel.

When Is A Quote Not A Quote?

Tue, 23 Sep 2003 01:04:05 GMT

When it’s a prime.

No that isn’t a very unfunny joke, it’s actually a good description of a problem with typography on the web. Typography has evolved on the printed page over several hundred years, recently much of it has been ignored on the web.

I’m going to explain how you can use correct typography on the web, and how this will lead to a more readable web page, and readability means a more enjoyable experience for a user.

What This Article Aims To Do…

By the end of this, if I do my job right, you should know more about correct typography in documents, and how to use it in your web pages. Not only that, but you should also have a useful visual reference for all of them.

…And What It Doesn’t.

I’m not trying to write an English essay here, I’m trying to show you practical examples of how typography works. At the end of the day it should make your document more readable, and professional looking, not provide an academically accurate typography essay.

While some of the fine details may be glossed over, you should get all you need to know to use the characters properly, and how to insert them in html documents.

So What’s This Prime Thing?

What is normally perceived as the double quote (the " character, normally above the number two on a keyboard) is often rendered as a double prime, what you should be using for inches. The apostrophe is also often incorrectly substituted for a single prime—used for feet—or a single quote.

Feet and inches aren’t the only applications for the primes, but they are the most common.

The two straight lines in this character are quite fine for coding or similar uses (like when used to surround attribute values in HTML), but they are typographically incorrect. This character is actually a single uniform general quotation mark—quite similar to what is rendered in many fonts as a prime—called the APL quote.

HTML does allow correct rendering of both single and double primes, and they do (when correctly rendered) look different to the APL-quote and apostrophe, but I will cover that later.

This is more a typographical issue than technical though, and whether your text editor uses primes or the APL-quote both are still incorrect for text presentation. You should be using single or double quotes.

But They Look The Same!

Not really, but some applications convert the APL-quote into the correct double quotes, and the apostrophe into single quotes as that is what you usually want. Microsoft Word does this for example. This can create problems of its own though—like putting in primes for feet and inches, or inserting a correct apostrophe.

However there is a visual difference. Allow me to illustrate:

"This is how you are probably used to seeing quotes on the web. Notice the shape of the character at either end. The same character, and straight lines."

“However this text is in double quotes, note the obvious visual difference. Also notice how they are actually two different characters. One is an opening quote and the other is for closing the quote.”

Proper quotation marks are more readable, there’s five hundred years of typography to prove that. They make your text flow across the page nicer and they are more pleasing to the eye.

Not to mention its actually the correct thing to use!

But… Who Cares?

Well, as it is an integral part of typographical standards, correct layout, and good general presentation… you should really.

These conventions make your text look smarter, more legible, more professional. It also makes you the writer look like you know what you are talking about, as it is a more professional presentation. As another point of note, single quotes should also only ever really be used when quoting within an existing quote.

However quotes aren’t the only thing that suffer from being misused or neglected. Hyphens, ellipsis, and numerical symbols are all misunderstood on the web.

Dash It All.

A hyphen isn’t a dash—and vice-versa—but it is commonly used in place of the correct dashes on the web.

The actual character rendered by the hyphen/minus key on your keyboard is called, appropriately, the hyphen-minus. It is a bit of both and totally neither, however it is much more appropriate for a hyphen than a minus, as it lacks the length needed for the minus. Use it for a hyphen, as it looks almost the same, but never for a minus.

Equally the only correct application for a hyphen is the one used above—to split a word in the correct place. Examples of such are the words ‘re-read’, ‘vice-versa’, or similar split words.

The Em Dash
If you’ve spent anytime looking into CSS then you will have probably come across Em’s before. An Em is described as the width of a capital M. In practice that may vary a bit depending on the font, so it is more standard for the Em to be the same width as the number of points it is being displayed as—so it is 12 points wide when displayed at 12pt.

Can you guess how wide an Em dash is? Thought you might be able to.

Its uses are pretty well defined. It can be used instead of a colon or semi-colon to link clauses, or as a substitute for unknown date ranges (like 1980—, for someone’s birth date where the death is unknown or 19— for an incomplete date). Also two adjacent Em dashes (a 2-em dash) are used to indicate missing letters in a word. For example, censoring letters in swearwords.

The most common uses of an Em dash however are to show a break in thought, or a parenthetical statement that is more significant than regular brackets would indicate. You can see the em dash at work above, parenthenising the ‘and vice-versa’ in the first paragraph.

The En Dash
The En is the half the size of an Em (in theory the width of a N). Some people like to use an En dash surrounded by spaces instead of an Em dash, which is valid, but there is little point in using it that way.

Its most common use is to substitute for the word “to”, or to indicate a range of almost any sort (like the London–Glasgow railway line, or 1–100).

Some applications of it might be to show sports scores, dates, document pages, or just for correct range display. Certainly you should use it in any numbered range.

The Ellipsis.

You know when you see those three periods together (like so...) that there is actually a proper character for that? Well there is, its called an Ellipsis.

The ellipsis should be used to indicate missing text in a quotation, or that a quotation trails off. Like so:

“Two households, both alike in dignity,
In fair Verona, where we lay our scene,
From ancient grudge break to new mutiny,
Where civil blood makes civil hands unclean…”

Note that it does actually looks subtly different to three periods. There are some rules with the ellipsis, but it is enough to know that if you are cutting out text from a quote, or trailing off then you should use it.

Math Symbols.

There is an annoying trend for, even in professional publications, using an x or * for multiplication, a slash for division, and a hyphen for subtraction. This convention comes from the coding world—and is fine to use when you are dealing with code or similar works—but shouldn’t be used in general practice.

See the following comparison:

3x10-6=48/2

compared with:

3×10−6=48÷2

While the slash might be useful in certain cases, for fractions or similar displays, the multiplication and minus symbols are a lot clearer in the latter case. It was for this reason I recommended against using a hyphen for the minus symbol earlier.

Other Symbols.

Not a day goes past without seeing someone substitute (TM) for ™ and (C) for ©, not to mention (R) for ®. Why this continues I don’t know, not only does it look clumsy, it also can be dangerous to the person that uses them.

None of the above substitutions have ever been given legal force or merit so, in some countries, there could be potentially damaging legal problems for someone who used the above substitutions.

However the characters are east to reproduce in HTML, so there should never be this problem.

Ok Genius, How Do I Get These Things In My Web Page?

Good Question. There isn’t much point knowing about these things unless you have a practical way of using them.

The answer is pretty simple too. You use decimal entity codes.

I Use What?

Decimal entity codes.

Entity codes come in three flavours—named, decimal, and hexadecimal. All of them start with the & character. The named ones used a & followed by a name, the decimal use &# followed by a number, and the hexadecimal use &#x followed by the hex value of the character. All of them end in a semi-colon.

For example to produce the < character you could use < < or <. Whichever you use is up to you, however there are browser issues to consider.

Most browsers don’t fully support named entitles—or only support a small commonly used set—and support for hexadecimal ones is even worse. However all browsers seem to support decimal notation.

If your text editor supports UTF-8 encoding, and your document is set up to use it (it’s the default for XHTML and XML documents) then you don’t have to worry about inserting codes as the characters will display normally. However there are the same browser issues to consider here, not to mention that many text editors don’t support UTF-8, sadly.

If you don’t know what UTF-8 is, or are unsure if your document or text editor supports it, I would recommend using decimal notation. I would recommend using decimal codes as good general practice anyhow, unless you know a named entity is supported (like   the non-breaking space is, or the above less-than symbol).

HTML Code Reference.

Please note, these are the correct codes for you to use. Far, far too many books and articles online quote the wrong codes. All the ones below are verified and work correctly. Note that the named entities are case sensitive, and that the APL-Quote is provided for reference.

Character Name	Character	Named	Decimal	Hex
APL Quote	"	"	"	"
Double Quote (left)	“	“	“	“
Double Quote (right)	”	”	”	”
Single Quote (left)	‘	‘	‘	‘
Single Quote (right)	’	’	’	’
Prime	′	′	′	′
Double Prime	″	″	″	″
Em Dash	—	—	—	–
En Dash	–	–	–	–
Minus	−	−	−	−
Multiplication Symbol	×	×	×	×
Division Symbol	÷	÷	÷	÷
Ellipsis	…	…	…	…
Copyright Symbol	©	©	©	©
Trademark	™	™	™	™
Registered Trademark	®	®	®	®

Hopefully these codes should make using the correct typography easier in your documents.

Good News For DreamWeaver Users.

Yes oh Macromedia converts, if you have DreamWeaver MX then its symbol entities are correct, and it will even convert between the APL-quote and the double quotes automatically if you are in design view.

However if you use DreamWeaver 4 or below please be aware that it inserts incorrect entities, and also contains some other bad code (like broken or invalid DocTypes for example). Time to get that upgrade perhaps?

At least they got it right in the end (mostly).

At The End Of The Day.

Hopefully the advice and instruction I’ve given here has informed you about how to use correct typography in your web pages. I don’t pretend I use all of it all the time, but knowing that it is there is they key to being able to construct a professional looking, and reading, web site.

Armed with this knowledge you should create more readable and pleasant content for your users. Also your pages should make the transition to print much easier, something that can be also greatly improved using style sheets.

However, that is a topic for another day.

PNG Corrections and Updates

Tue, 16 Sep 2003 02:59:45 GMT

*UPDATE 2/2/2004 - After the release of a new version of PhotoShop, VIMAS Web Image Guru, and Ken's PNGOut (see below) I decided to check if the improvments effected the final sizes at all see this entry I made for more details.

Ken Silverman corrected me in reference to his PNGOut utility that I used in my recent PNG article. I had stated that PNGOut was a - "Quite popular implementation of the Libpng code library..." and I was wholly incorrect as it turns out. As Ken himself puts it:

"I have never used libpng or zlib. I wrote my own library from scratch based on public documentation of the format. It was a lot of extra work on my part, but I think it was worth it. This is why PNGOUT behaves differently than most other PNG applications (in size, speed, etc...)"

Mea culpa, mea culpa.

Or to take a line from The Gospel Of Buffy - My bad.

I had been reading so much about Libpng I guess my mind ran off with me, whoops. I'm glad he corrected me, as I wouldn't want his hard work to be attributed to someone else, and I think the results show that it was indeed worth it.

However an interesting side effect of this was that Ken was moved to action to play with his own utility. He found something very interesting, and an equally interesting solution:

"Using my current version of PNGOUT, I was not able to compress unionjack that small! So I did some research. PNG Gauntlet includes an old version of PNGOUT. I've made some changes to PNGOUT since then. [...] I learned that the thing that made the biggest difference was the palette order. In the version you used, PNGOUT preserved the palette order if the input was a PNG file using a palette. My current version (now old) re-generated the palette (changing the order of palette entries) no matter what. It turns out unionjack.png was one of those files that compressed better with the original palette order - about a 100 bytes better.

The point is, your sample inspired me to make some changes :) Now, PNGOUT works like this: If you put /c3 on the command line, it will generate a new palette. If you omit /c3, it will preserve the palette order. The difference now is that you can choose what you want. As a bonus, PNGOUT now defaults to paletted files when the input is a .GIF file."

Well... wow. I'm glad that something I wrote will have a positive effect on PNGOut and PNG users in general. I could not be more pleased right now.

Ken also sent me a new Union Jack image that he'd managed to compress using his new version down to 2.95kb (3030 bytes), that version is now the one on display in the article. Forever getting smaller, I wonder if we can get it down to below 3000 bytes, anyone want to take the challenge?

You can get the brand new PNGOut here at Ken's website.

PING!

Mon, 15 Sep 2003 15:30:22 GMT

*UPDATE 17/9/2003 - Corrected some minor errors. Also this article has helped contributed to the development of PNGOut see this entry I made for more details.

One of the sad things about web standards is that they aren’t. Various browsers implement the standards in different ways, or in many cases, fail to implement them properly. The most notable failure is Internet Explorer, even the new version, but Gecko based browsers (Mozilla, Netscape, etc) still have serious issues, not to mention other browsers.

One weird browser inconsistency is the implementation of PNG files (pronounced ‘ping’). PNG is a format that has been around for a long time, and I am a great fan of, but still isn’t used as much as it should be. If you don’t know about it – you should do.

PNG’s Are Better Than GIFs.

There, I said it. It’s a statement based on fact. PNG supersedes GIF in almost every way, the only exception is animation, which PNG doesn’t support (though its companion format MNG does). There’s no quibbling about this, its cold hard fact. I’m going to illustrate this with some tests I’ve performed, but first a little history for those that may not know much about PNG.

PNG is a replacement for GIF (pronounced with a soft g like in gerbil – ‘jif’, not ‘guh-if’ – so says the creator of the format.) which you all should have heard of. It was designed because Gif was getting very old (created in 1987) and was really out of date in ’95 when the PNG specification was drawn up. Another factor was that UniSys decided to start calling in licensing charges for the LZW compression that Gif uses, it hadn’t before… and so a free format was born.

Implementation of this format was slow however. Currently all browsers support the display of PNG files, but not all of the features of the format.

What Are PNG’s Features?

Lossless Compression – Unlike JPEG which throw away data and guess how an image is composed, PNG compression never throws away information. This avoids the artefacts and blurring you often find in JPEGs.

Multiple Bit Depths – While GIF is commonly only supported in 8bit palettes (256 colours) and JPEG is only 24bit (16.7 million). PNG supports any bit depth to the power of two – from 1bit (2 colours) to 48bit (too many to even count). Though the most common formats are 8bit and 24bit. However it must be stressed PNGs at depths over 8bit were designed for perfect lossless archival quality with good compression, and are not designed to compete with JPEG for 24bit web use.

Gamma Correction – Gamma correction, in applications that support it, ensures images appear the same across all platforms. Even across Windows and Macintosh there is a large difference in display.

Alpha Information – PNG supports multiple modes of transparency. Alpha channels for 24bit images, RGBA for palette images (where not only a value for Red Green and Blue is stored, but one for Alpha), and binary (GIF style – either transparent or not) transparency.

Interlacing – PNG supports interlacing (progressive display of images while they are loading) like both GIF and JPEG. It works in a different way to GIFs and is considered one of the better interlacing display methods available.

Smaller File Sizes Than GIFs – PNGs compression algorithm is better, and produces smaller files than GIFs for 8bit images. At least.. it should, as I will soon demonstrate.

But… Why Should I Use It?

Simply because, as I’ve said before, its better. File sizes are usually significantly smaller, and that means lower bandwidth and shorter download times. For the web these are the primary reasons for any choice of format. It’s that simple – PNGs will save you bandwidth, and hence money, in the long run.

Much is often made of the lack of browser support for PNGs alpha transparency in some browsers (well.. just IE/Win I think now, IE/Mac does a fine job). This is missing the point – for GIFs are surviving on binary transparency just fine, and everyone still uses them – an outdated format that is over 16 years old!

While the artistic and design community may want to have better transparency, we can cope – for now at least – with doing it the way GIF has done. The more support PNG has, the more incentive for developers to support its features, like alpha palettes. The more we use PNG, the less we rely on old outdated GIFS.

I Thought PNGs Were Larger Than GIFs.

Not at all! Or at least, they shouldn’t be. This is a myth that is spread mostly because of the appalling compression in Adobe PhotoShop. Really.. its that bad. PNG leaves some room to manoeuvre with how a program compresses the files, Adobe has obviously not tried to optimise things at all. Things did improve with their ‘Save For Web’ option (basically using the code from ImageReady) but it's still the worst around.

However, there are many ways to fix that, even with files that have already been saved.

The Software

This is the software I’ll be using to illustrate the benefits of PNG compression. I have separated them into freeware utilities, and commercial applications. The main difference being that the freeware software needs a PNG file to work with, while using the commercial software I can work from any file.

The following are commercial applications:
Adobe Photoshop – The standard for graphics software.
Web Image Guru – A suite of utilities, including a plug-in for Adobe PhotoShop that mimics the Save For Web features. Apparently has excellent compression.

The following are freeware utilities:
PNGCrush – the original, and now standard, for PNG compressing utilities.
OptiPNG – Similar application to PNGCrush, claims it has “a wider automatic search space (which may lead to a better compression factor), and it runs faster.”
PNGOut – A self coded utility, written by Ken Silverman (of 3D Realms fame). Claims to beat PNGCrush significantly.
PNGRewrite – Not really a compression program. PNGRewrite aims to optimise the palette of the file (bit depth, palette order, transparency info.. etc) not optimise the compression, and hence reduce the file size. In theory this should be done in any application, but most don’t perform well.

The freeware apps are all command line apps, but for PNGOut and PNGRewrite I’ll be using a free windows shell for them called PNG Gauntlet. All this does is provide a friendly windows interface for the two programs. To run PNG Gauntlet you need to have Microsoft .NET 1.1 installed, but many people do now anyhow.

This is the image I’m using –

A simple image of the Union Jack, clean colour space, with some anti-aliasing between the colours. it’s the kind of image that is ideal for 8bit palettes, and the sort of thing that might realistically be on a web page. Moreover – it is the exact kind of image someone might save to GIF. Perfect for what I’ll be testing.

Both the PNGs and the GIF are saved using Adaptive palettes. While Perceptual can often be better with complex images, Adaptive performs best at lower bit depths and simpler images.

The GIF of this image is 4.62 KB (4,734 bytes), around what you would expect.

I created this image in PhotoShop initially, so it made sense to test out Web Image Guru (WG) and PS first. Equally the other utilities only work on existing PNG files.

PS Test - 5.73 KB (5,870 bytes)
WG Test - 3.16 KB (3,236 bytes)

Woah, that’s a huge difference! Surely that can’t be all down to compression?

No, its not. After a look at what was going on I noticed that PS was including a full 256 palette entries, while WG said there were only 99 colours needed. Indeed a per pixel comparison confirmed this.

Lowering the number of colours in PS produced the same image, but with a lower file size. Interestingly I found that saving the image to BMP (24bit), opening the file, and then saving for web made PS agree that there were indeed only 99 colours.

Obviously there is something in working from its own format that causes PS to act strangely when saving to web. Here’s a comparison with the new file

PS Test 2 - 4.12 KB (4,225 bytes)
WG Test - 3.16 KB (3,236 bytes)

1.5kb removed, just by doing something that PS should be doing itself. From here I decided to compare the optimisation utilities on both the PS tests and the WG test as they are produced from the same base file.
N.B. – Web Guru can optimise files by itself, not using the PS plug-in, and managed to optimise the original PS test. However as it only managed to optimise it down to 130 colours the image would appear to not contain the same information. The new files are exactly the same in contents, and so a fair comparison can be achieved. It is rather worrying that the original PS saved image appears to introduce colour information into the image.

Final Results.

In Red are images that are larger than the GIF,
In Green are images that are smaller than the GIF.
In Blue is the smallest file.
In Purple are files of note.

	PS Test 1	PS Test 2	Web Guru
Original	5.73 KB (5,870)	4.12 KB (4,225)	3.16 KB (3,236)
PNGCrush	5.09 KB (5,220)	3.36 KB (3,441)	3.18 KB (3,257)
OptiPNG	5.07 KB (5,199)	3.33 KB (3,420)	[no change]
PNGOut	4.79 KB (4,908)	3.10 KB (3,183)	2.97 KB (3,044)
PNGRewrite	5.21 KB (5,340)	3.49 KB (3,578)	3.43 KB (3,519)
PNG Gauntlet (both PO and PR)	4.77 KB (4,887)	3.10 KB (3,183)	3.03 KB (3,105)

PG test on PS1 – Note that this is the smallest file from the original PS test, but it is still larger than the GIF. Its seems that PhotoShop PNGs saved using the default options are hard, and in this case impossible, to reduce down to a level below GIFs. Probably due to the redundant (or possibly introduced) colour information. This is totally unsatisfactory in such an expensive and supposedly standard application.

PC test on WG – Note that PNGCrush actually increases the file size of the image. While it decreased file size in the case of poorly compressed images, it still performed the most poorly overall, however it is the oldest utility on test.

PR test on WG – PNGRewrite also increases the file size, but in this case by a significant amount! It may be that the original file was already better ordered than PR can achieve, however this is still puzzling.

Best PNG file size = 2.97kb (3,044 bytes)
Total PNG saving over GIF = 1.65kb (1,690 bytes) a saving of 35%

Ok, its smaller, so what?

Well, smaller files mean faster loading page, less server space being used, and less bandwidth being used.

Whether you are hosted with a professional hosting company, or Geocities bandwidth is important to you. Bandwidth costs money, and the more you use the more money you spend. With some hosting services, especially the free ones, your site won’t work if you exceed your monthly quota of bandwidth.

Lets put this in real terms. Say you have a moderately popular site, about 1000 page views a day, quite achievable really. What would you save in our above example?

48.35mb/month

That’s for one image! One! And a small one at that. Think about how many images, GIF images, there are on most web pages. Only 21 similar images would be needed to make that over 1gb of bandwidth savings a month!

Suggestions For Everyone.

Simply put… switch over to using PNG files in your work. It’s better for you, your client, and the future of the web. However, due to Photoshop’s awful support I have some recommendations for saving to PNG.

In PhotoShop - Save As Another Format First. If you already have saved out as GIF then this isn’t a problem, just open up the files and save them as PNG using Save For Web. This gets rid of the confused colour information side effect that PS shows. Important – when you load the files back in make sure you set the mode to RGB not Indexed or this will again cause problems. This isn’t a problem if you haven’t saved to a palette image format like GIF, I used 24bit Bitmaps for the second PhotoShop test.

Use PNGOut On Your PNG Files. Or use PNG Gauntlet to help you. PNGOut performed excellently on all files, and even compressed the excellent Web Image Guru test image. Simply the best utility I’ve found for PNG compression.

As another recommendation I would suggest using the excellent Web Image Guru, while PNGOut still managed to compress its PNG files the starting standard was excellent, and in combination with PNGOut it produced the best file size overall. Also, as it is not just a PhotoShop plug-in, you can batch covert whole directories of GIFs - or other image formats - over to PNG or anything else that catches your fancy. At $39 it’s a excellent investment.

To Finish.

Well.. that was a bit longer than usual wasn’t it?

I hope that I’ve successfully proven that PNG is a practical and economical replacement for the creaky old GIF format. I didn’t even cover in much depth its additional features that will eventually help everyone make more attractive web pages, and yet I think it is apparent that it is already the superior format.

Here’s to seeing more PNGs in web pages, faster loading times, and lower costs. I think we can all look forward to that.

If you would like to know more about the png format, check out this comprehensive guide at libpng.org

Geek vs Nerd

Mon, 08 Sep 2003 17:11:37 GMT

A light-hearted post today.

I thought I'd explain, as I see it, the difference between a geek and a nerd.

What Makes A Geek/Nerd?

Geek and nerd aren't specific computer related terms. You can be geeky or nerdy about any subject. Cars for example.. they have plenty of geeks and nerds. How do you say? Well I'll explain shortly.

For the most part geeks and nerds tend to be involved in things with a lot of detail. They both exhibit a knowledge of their subject beyond what a lay person may even think is possible. Indeed, that could be the very definition of where the boundaries lie. Good examples of this could be: role-play games, cars, computers (of course), or fitness.

The Geek

A geek is someone that uses their field for productivity or pleasure, and has accumulated - through a desire to enjoy their experience more or become more proficient at a task - an extensive knowledge of a subject.

Geeks that are involved with machines (cars, computers, stereos, etc) tend to see these things as tools, and by gaining more knowledge about - and hence control over - them they intend to maximise their use of the tool. Be it driving better and for longer, or being able to code an efficient web page without looking at a reference book. The result is the same in terms of difference to a layperson. This type of geek will often know lots about the construction of their area, and can be excited by the prospect of upgrading a small part that may seem insignificant to an outsider, but it impacts (or the geek feels it impacts) the performance of their tasks.

Geeks tend to be concerned with issues in a broader scope than nerds, and are certainly more focused on issues that affect them (this journal for example - web design, and similar issues) and less with the minutiae of details.

The Nerd

A Nerd is someone that has taken their use of a tool or discipline and raised it so that they no longer value the result of it more than the tool or discipline itself. It is the subject that is their love. A geek might know a lot about computers, but it will be what they need to know. A nerd will learn everything they can about computers, but gain no practical benefit for this. Moreover they will experiment with things that will take a lot of time and have no real benefit to them - just because they are learning about the subject.

Nerds tend to be even more fanatical about improving in their subject than geeks, but have a more holistic approach. Rather than improving in their area they must improve overall in all areas.

Nerds are usually the more preachy and anal of the two (though this does depend to some extent on personality - a geek can be an arse too!) and are more prone to nitpicking small irrelevant details and using this as an excuse to junk the rest of the information. This is related to that Nerds are often the hardest group to teach, as their knowledge is sacred to them - and so can never be proved wrong. Sometimes even when presented with overwhelming evidence to the contrary a nerd will still claim that their knowledge is correct.

Nerds are the more annoying of the two, and the most observed. They are highly critical, and tend to put down people rather than help them (as most geeks will try to do - until they lose patience). Often the distinction is missed between these two groups, as the Nerd is usually heard the most.

In Summary

Without Nerds there would be less pushing of the boundaries, but without Geeks no-one would find these things useful. Remember a geek or a nerd doesn't actually have to have a certain amount of knowledge, it is an attitude to their subject that creates the geek.

Geeks and Nerds are closely related, in fact many nerds will start out as geeks - a starter techie if you will. Geek shouldn't be a negative term, as it merely infers knowledge. Nerd is more negative, mainly due to the unhealthy obsessive nature of the classic Nerd, however the benefit a Nerd can have on a subject should not be overlooked either.

Viva La Difference!

Of course making your own definition of Geeks and Nerds certainly qualifies you for one of the categories… which one is up to you…

Wed, 27 Aug 2003 21:42:09 GMT

Doug Bowman of StopDesign.com recently posted a counter point to Jason Kottke's post on standards complience and semantics at Kottke.org in which he argues againsts Jasons assertion that:

"Coding web documents in valid XHTML doesn’t make them semantically useful nor does coding semantically correct documents mean the documents are standards-compliant"

Dougie disagrees and thinks that it is a designers 'natural tendancy' to code meaniful markup if they are standards complient. Seemingly the only reason for this is his assumption that people will want to make code pretty. He goes so far to say:

"A page full of nothing more than divs, spans, and br’s might be perfectly compliant in its use of standards. But generic markup like this will appear anemic in comparison to well-structured documents."

This assumes a couple of big glaring things as far as I can see..

Most webpages are coded by designers.

Most webpages coders care about the presentation of their code.

Most webpages are created by people that aren't lazy.

I think these are not only Dougs assumptions, but an assumption by a lot of people in the 'web design community'. Its a set of assumptions that have pretty much created the situation that so many of them are trying to change today - something that Doug actaully seems to understand in the last lines of his post where he says

""one without the other won’t get us much further than where we’ve been in the not-so-distant past.""

This is very true.

And how Doug can make that statement after a whole post of trying to persuade us that they are already skipping down the street together - if not actually hand in hand - I don't know.

You see I actually agree with both of them. I agree with Jasons' conclusions, but I also agree with Doug that most people who code if they do any research into standards will start to code meaningfully (semantically better).

The trouble is I have zero faith that most people will bother to learn about the code. Think about it, how many people that you know have any care what their code is as long as it looks ok when its displayed? Moreover, how many designers really want to get down and dirty with the code as long as they can use a nifty little program to create their design that doesn't involve them actually messing with the code?

These people probably make up most of the actual 'web designers' that are out there, sure they may not code the big sites, or produce the best content, but by volume they are the biggest producers. I have no figures to produce, but think about it for a second... look around the web. These are the people that need to be sold on standards and semantics. Why? Because if they don't.. then its going to be another 5 years of spacer gifs and tables filled with non-breaking space codes.

The web exploded because the average person could look at html and pick it up and code it, I know thats what I did. Standards complience should make it easier to understand the content and meaning of the code, and style sheets will make layout more obvious. However if the average joe doesn't know this then where will the next generation of web designers and coders come from?

The Basics Pt 3

Fri, 22 Aug 2003 18:35:58 GMT

Why All The Fuss Over Web Standards?

Mainly this is to do with the goal of the strict standards, which is to separate style from content in web pages.

This means that the code on a web page should be structural, any tags should be meaningful not concerned with the presentation of the page. Presentation should be handled by CSS. More on CSS later.

An example of using meaningful code can be illustrated using the bold and italic tags and . These tags have no meaning by themselves. When we read bold or italic text we attach meaning to it however - bold is interpreted as words that are being stressed, and italic is text that is being emphasised. It is for this reason that browsers also support the tags and . These two tags give meaning to the text that cannot be conveyed by style alone.

If you need to change a section of text to bold for stylistic purposes then you shouldn't be using or even in your code - you should be using style sheets to do that. That is what they are for.

Why Is Meaningful, Style Separated Code Important?

For two reasons: Portability and Accessibility.

Portability means that your code will be understandable not just across different browsers like IE and Mozilla, but across different platforms. This includes computer OS's like Windows, MacOS, and Linux, but more importantly across platforms like mobile phones, PDA's, and other equipment that can access the internet. While all of these may not be supported straight away these methods will allow your code to be transferred into the right format with the minimum of effort. Who can say that about a page with miles of nested tables?

Accessibility means that users who may not be able to use the net like the majority of people can access your site. They may use screen readers if they are partially sighted or blind, or have special browsers to make things more convenient. Either way the content of your site will still be viewable and meaningful to them. Not only is this allowing more potential viewers of your site, it may in fact be a legal requirement now for many businesses.

Basically it is maximising the availability of your content. This means that more people can see your work. Of course there are other more practical benefits to using style separated code as well, I'll cover these as I go on.

The Concept of Tableless Design

Tables are another example of where structural code has been misused for design purposes. In the past it was common to work out a way where you could split your design into rows and columns so you could display it in a table. It is such a common way of thinking now that many web designers have trouble not thinking in these terms.

However tables are designed to display tabular information, not to act as a stylistic tool. This is where the idea of tableless design comes in - using tables only to display tabular information. If your content requires a table, by all means put a table in there. What you should not be doing is using them to control the layout of your page. This just leads to ugly, nested tables, lots and lots of code and, above all else - a website whose' content is meaningless.

Sometimes it can be useful to use tables to define the basic structure of your page. In this case it is a semi-valid use - it is a structural element after all, and this method may help display your page in some older browsers that don't support style sheets. However I would not suggest it, mostly because there is no need to do so, and it can lead to more problems than it solves. It is a good solution for people just getting into style sheets and learning how to work with them though.

Rather than thinking of your page as a set of rows and columns, think of it as if it is split into any number of boxes. In each box is an element of your page. These boxes don't have to be aligned with each other, or even be next to each other - they could overlap for example. This is the concept of tableless design.

Each box would be an item, be it an image, a block of information enclosed in a <div> tag, some text in a tag, or anything else on a page. Each of these elements would be controlled and positioned using CSS, allowing much greater flexibility in design, while keeping your actual code clean and simple.

How Does This All Benefit Me?

Coming down to brass tacks, most viewers don't care how their page is coded, just that it displays properly. So what does all this mean in a practical sense? As Jerry Maguire might say - show me the money.

Smaller Pages - Because you aren't using lots of nested based markup that wasn't designed to be used for presentation or tag specific attributes you'll find that the pages you author are smaller in file size. Meaning that you use your web space better, and have more room for more content.

Faster Loading, Lower Bandwidth - because your page size is smaller and the style sheet only needs to be loaded once you'll find your pages loading faster. Being smaller also means you'll use less bandwidth - which saves you, or your client, money.

Less Work - That’s right, less work for you. Coding and working with table based layouts can be time consuming, and boring. You end up repeating large blocks of your code needlessly - especially when you are using the same or similar layout in every page (as almost all sites do). If you separate the style from the content all you need to do to design your entire site is to work with one file.

Easy To Redesign - have you ever tried to redesign a nested table layout that you coded a year or two before? If you have then you'll know that it is a tiresome and will sapping task - and that’s when you coded it, let alone some other developer. When the content is separated however all you have to is change the style sheet and you can have a totally different look in minutes.

Get The Design You Want - Often many designers have had to compromise their design because certain things just weren't practical. With style sheets designers have full control over their design and, while not as flexible as a professional design package, much more can be done - like pixel based layout for example.

Access To More Viewers - If you code and design intelligently then more people will be able to see your site than ever before. Also you could be saving you or your client possible legal issues in the future.

Hopefully this demonstrates not just the usefulness of complying with web standards, but the business sense it makes - both in short and long term. A design will have less problems, a coder will have less headaches, and a client will save money.

Just remember all this for the next time you hear someone say that there is no reason to use web standards.

The Basics Pt 2

Fri, 22 Aug 2003 16:51:38 GMT

Currently I'm covering the simple - but important - concepts that I think everyone should know so they can create better web content, design, or code. The last entry was about DocTypes, and how they can help you be standards compliant. However, this leads to other questions...

What Is Standards Compliance, and Why Is It a Good Thing?

The term 'standards compliance' tends to be flung around quite a lot these days, often incorrectly, or at least with some degree of misunderstanding.

All standards compliance means is that web sites and browsers confirm to certain suggestions made by the w3 organisation. These 'recommendations' for each form of html and other web languages form the standards. The ultimate goal of this is so that sites will look the same no matter what platform you view them on.

Its that simple, standards mean you can rely on your code acting the same, and being understandable, in different browsers and on different platforms. Sounds easy doesn't it?

However this is where it gets tricky. Currently no single browser is standards compliant. None of them. They all claim to be, but they lie. The ones with the least bugs (very few) are Mozilla and Opera. Internet Explorer does the job, especially in v6, but still has many more problems then either of the other two. One thing to note about Mozilla and Opera is that they update much more than IE, and this is almost certainly the primary reason for their better support.

These bugs shouldn't be a problem for many designers however, as often (though sadly not always) these bugs may not cause an obvious problem, or they have simple workarounds. Soon, I hope, there will be no need to have workarounds.

The Bottom Line

Authoring your web pages to be standards compliant will make sure that your site is seen by more people how you want it to be seen. That is better for the viewer, and better for you.

The Basics

Thu, 21 Aug 2003 20:32:33 GMT

To start this off in the next few posts I'll be covering the basics, and yes, some people may think the following is obvious, but it never hurts to make sure that everyone is on the same page.

Why You Should Be Using DocTypes

Using a correct DocType is the single most important thing to do in creating a webpage. Sadly many authoring tools actually insert incorrect or broken doctypes in the code they create. Doctypes are what tells the browser the kind of page it is expecting. This is especially important as correct doctypes help browsers to render the page in 'standards compliant' mode, turning off all the goofy features that other, badly coded, pages might need - and that screw up all your hard work.

Of course you don't need these features because your web page is going to be coded properly right? Right? Right.

Why are there these features in browsers? To compensate for the awful coding people have done in the past for the sake of 'backward compatibility' that’s why. Its the browsers fault originally of course, the war for dominance in the browser market created many of the problems that are now trying to be fixed. Due to this many web pages have code that is frankly incompetently coded - with unclosed tags and typos within the code. Putting a doctype in your code lets the browser know that you are coding to a certain specification, and that it should display it as such.

In fact having a doctype (and code that complies with it) is the single biggest step anyone can take to making their site look good, and more importantly consistent, on all platforms.

So What Is A DocType?

DocType stands for 'document type declaration' or 'DTD' and basically does just that - declare the type of document that it is. They usually come in 3 flavours - Strict, Transitional, and Frameset.

Strict - Strict is just that, its a strict set of rules that conform to the wc3's recommendations for web standards. It doesn't allow any tags or properties that have been depreciated in the specification, and you should have content and presentation separated. Ideally this is what you should be working with, especially if you are creating a site from scratch.

Transitional - Much friendlier for many people, transitional understands that you may not be able to, or may not want to code to the ideals of the strict doctype. It features the depreciated attributes, and doesn't require you to remove content from presentation as much. A good doctype to start with if.

Frameset - This is the same as transitional, but with support for the outdated and often misused html frames.

DocTypes also vary depending on what language you are coding in, HTML, XHTML 1, or XHTML 1.1. The difference between html and xhtml is subtle, but important. However I'm not going to cover this today, if you don't know the difference then you are very probably using html.

What DocType Should You Use?

Good question, its quite hard to find correct doctypes on the net, even when someone declares one it is often wrong. To explain why lets look at a DocType, in this case for HTML 4 Strict:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
	   "http://www.w3.org/TR/html4/strict.dtd">

This pretty much breaks down to three sections. Telling that its a public doctype for html, the actual definition of the type, and the url to the specification of the type. Note the FULL url in the code. Often this is written as 'TR/html4/strict.dtd' or 'strict.dtd' this is wrong! You must include the full url in the doctype else it is invalid and will do nothing for you.

With that lets show you the valid doctypes:

HTML 4.01 Strict

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
	   "http://www.w3.org/TR/html4/strict.dtd">

HTML 4.01 Transitional

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
	   "http://www.w3.org/TR/html4/loose.dtd">

HTML 4.01 Frameset

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
	   "http://www.w3.org/TR/html4/frameset.dtd">

XHTML 1.0 Strict

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

XHTML 1.0 Transitional

<DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

XHTML 1.0 Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
	   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

XHTML 1.1 (No transitional or frameset)

<DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" 
	   "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

That’s all of them. They go just like that in your code as the first thing in the file before any other tag, even the html tag. You can check that you are conforming to the standard that you've declared in your doctype by validating your code (check the links side panel for the w3.org's validator). You should try to eliminate any warnings and definately get rid of any errors it displays. In the long run you'll learn how to code better displayed pages so that your site is fast, and the design looks right across all platforms.

Congratulations on the first step towards a better web.