First, how much bet­ter so­me compa­nies’ iPhone apps are than their web si­tes, as if the compa­ny is somehow so much more gifted at cre­ating iPhone apps than web pages.

The compa­nies are not more gifted in de­si­g­ning for a smal­ler screen but rather the tiny screen has forced them to show only the most important in­formati­on and cast away the un­important and use­less in­formati­on—the con­tent its­elf—leav­ing only the con­t­ents wi­th less or no dis­tracti­ons.

It might be arrogant of me to pre­dict the fu­ture of the web wi­th virtually no data to support my view but I see the fu­ture of the web—or at least I hope it will—to beco­me a place whe­re con­tent webs­i­tes will give emphasis to con­tent. As silly as it alre­ady sounds re­ading what I just wrote, today’s webs­i­tes are dictated by adver­tise­ments whe­re they spam you wi­th end­less, annoying ads. To make sure that they are able to bombard you wi­th as many ad im­pressi­on as pos­si­ble, they make a seem­ingly simple task 2 to 3 times har­der to do.

What I’m sugge­st­ing isn’t that the fu­ture of webs­i­tes would look li­ke the many mobile coun­terpart of their webs­i­te, but rather a much focused and clean in­terface wi­th just one quality adver­tise­ment. One adver­tise­ments might seem too lit­tle but the adver­tise­ment will get 100% at­tenti­on from the view­ers rather than bombard­ing them wi­th 3 or 4 sec­ond grade quality ads that one and only spot can be sold at a much high­er pri­ce. Wi­th less ad dis­tracti­on, the amount of visi­tors will only con­tinue to incre­ase which in turn can bring up the pri­ce of that sing­le ad spot.

No More House­keeping

As Kroc Camen puts it “Public com­ment threads just encour­age people to write a lot of words, and say noth­ing.”, and I do agree with that. When it comes to blog com­ments on the web, most of them are use­less. There are too many com­ments like “Great post, keep up the work!” & “This is a stupid post” that does noth­ing but clutter up the com­ment thread.

Some say having a community in­spires debate, but what I mainly observe is through the power of Inter­net anonymity, it mostly in­spires hit-and-run com­ments. Unintelligent, sense­less spams that in the end requires the site owner to do reg­ular house­keeping is a waste of time. Wast­ing time of the site owner where he or she could use that time to write a quality article.

It In­spires Debate

Quality rebuttals, the ones that results in quality exchange of ideas. It is one thing to post meaning­less com­ment on some­one’s blog, it is an­oth­er when you argue your points with your readers watch­ing. When oth­er people are looking you, its hard­er to make a fool of your­self. Who doesn’t care of their own rep­u­tation, especially those who have many readers fol­lowing and judging ev­ery­thing you type.

One example of this is when Kroc Camen linked one of my post. His com­ments was constructive, leav­ing me reflecting on some of the poor choic­es I made. It is no shame in be­ing told you are wrong, in fact I would ap­preciate it more when people points out what I’ve done wrong. How else can one be right with­out be­ing wrong?

Show What You Want To Show

Take this site for example, this website be­longs to me, it is written for people that wants to read my site. When my vis­itors vis­its my site, I expect them to read what I write. What I written has always been what I could to my best ability and I want my vis­itors to see what I want them to see.

That can nev­er hap­pen when the blog is bloated with com­ments. With the addition of com­ments, vis­itors that read the blog will need to skim through the con­tent and decide which con­tent is worth the look and which isn’t. That is noth­ing like what I imag­ine the vis­itors will need to behave when they come to this site.

What Then?

I am not here to suggest an al­ternative but people have been explor­ing differ­ent ways to bring the discus­sion elsewhere, be it with twitter or fo­rums. They all have their strengths and weak­nesses.

As for me I pre­fer the good old fash­ion email. It is been around longer than I have and it has served the people on the web quite well. Those who absolutely must get their com­ments out of their chest can email me. Those who just want to say hi can email me. Those who wants to inform me of their rebuttal can email me.

Take DaringFireball for example, the font size set on this website is 11px, that is extremely diffi­cult to read comfort­ably with­out plac­ing your face near your screen. Even it’s lev­el 1 heading is sized at 1.55em, that is 17.05px just about a pixel big­ger than the default font size.

It’s Not Big

When talked about 16px font size we im­me­diately say big font or large type. The fact is it is not big or large, it is the default size. Website us­ing font size small­er than 16px are the ones we should be call­ing small and yet 11px & 12px font size have dom­inate the mar­ket so such a long time it has been perceived as the default size by the viewers. Be­ing presented with the default font size now seem to be huge and odd.

The default font size is not odd, in fact, when you look at it again for a few times it almost seems right. The question then becomes “why isn’t most website us­ing the default font size?”.

To under­stand it we have to look at the old age. The time where com­put­ers are starting to gain public recog­nition, as a tool that can use at home to simplify our life. A time where the Inter­net is boom­ing. A time where displays are still rel­atively expensive and most website are faced with a prob­lem. The displays have low res­olution.

Us­ing the default size means that information is hard to display as 800×600 can’t display that many lines of words on the screen so we use a small­er font to get the message across. Us­ing a small­er font size makes sense back then but somehow web designers nev­er kept up with the display changes. We are no longer confined by 800×600, I don’t even have vis­itors view­ing this website with 800×600 res­olution. We find so much space in design and there are so many empty spaces on both sides and I don’t think anyone wants to fill them with 12px Hel­vet­ica.

It’s Small

Phys­ically 16px is about as big as 12pt in print. That is not at all big, most print ma­te­rial are print with this size. Add to that is that we normally read from a dis­tance much fur­ther than we do with print ma­te­rial, the impact is signif­icant.

The saying 95% of web design is typog­raphy should be fa­mil­iar to web designers—if it isn’t I suggest you don’t call your­self one to save your­self from embarrass­ment—then what is more important than to design your website to be eas­ily read with­out print­ing your face onto the screen ev­ery time you need to read—I be­lieve we have enough young chil­dren wearing glasses.

There is no rea­son at at all to squeeze that much information into the screen, in fact it is even rec­ommended by w3c. Having a font size big­ger or equiva­lent to 16px could also be ben­e­ficial to busi­nesses as well.

The prob­lem here is a ba­sic us­ability and ac­cessibility issue: a good design should look good with­out requiring the us­er to enlarge or reduce the text size.

Join Now

Change is hard. Why ven­ture into the un­known when we are comfort­able just the way we are?

We people are always resistant to change, a study howev­er have found that happi­ness can lift the mood of a per­son’s ex­tended network of friends and that very same support can influ­ence change in some­one. People are better able to change when people in their social network are chang­ing as well.

People are more likely to make pos­itive changes in their lives not only when their friends do, but when their friends of friends do, and when their friends of friends of friends do.

All it takes is just to de­fine the font size with font-size:100%;.

Web au­di­ence show a rel­atively short at­tention to posts and articles they find on the inter­net due to the massive amount of information avail­able. To go through ev­ery article in detail would be too time consum­ing, that is why the au­di­ence skim through, and yes, sometimes the good articles are mis­sed.

The goal of minimal design is to strip away unnec­essary design el­e­ments from your design, unnec­essary design el­e­ments that will only confuse the au­di­ence rather than keeping them inter­ested.

You know you’ve achieved per­fection in design, not when you have noth­ing more to add, but when you have noth­ing more to take away.

antoine de saint-exupéry

The common mis­conception about minimal design that it is used to focus the au­di­ence to the con­tent of the website rather than the vi­su­al presentation of the design. That is simply not true at all. Minimal design, like all design principles is to compli­ment and enhance it’s con­tent rather than to shift the au­di­ence’s at­tention to the con­tent.

Once a good design catches the at­tention of the au­di­ence, the au­di­ence will nat­urally find inter­est in exam­ining your con­tent. Minimal design merely does that more quickly than oth­ers due to the na­ture of the design.

Minimal design aims to de­liv­er a clear and di­rect message across to your au­di­ence. Cramming all the information you can find will only make a bad im­pres­sion on the au­di­ence and very of­ten the au­di­ence becomes uninter­ested and leaves.

Design is all about simplifying our life, enabling us to accomplish tasks more ef­fectively. If your prod­uct does that, I don’t see why your au­di­ence will not trusts you and return for more.

While we do our best to serve the files as fast as we can, it still wouldn’t be faster than serving them from cache. Bare in mind that only viewers that have pre­vi­ously vis­ited your site is able to save the files as cache in their com­put­ers and even for major websites like Yahoo!, 40% – 60% of their vis­itors arrive at their site with an empty cache.

web cache

The idea of web cache is to store frequently used objects clos­er to the viewers through var­ious means. By do­ing so your viewers avoid round trips to the web serv­er, saving bandwidth, serv­er load and most importantly faster loading, much faster loading.

There are many ways that you can set cache con­trol rules for your web site, the simplest way is through html <meta> tag, but like I said it produces ugly code and it is poorly support­ed by brows­er cache.

Cach­ing does not concern your viewers and they certainly don’t need to see your rules for cach­ing, the rules only concerns the browsers thus only the brows­er should be informed on how you want to cache your files. Writing the cache rules in your .htacess file would be the best way to achieve that goal.

caching methods

Last-Modified

When a brows­er sends its http request to a web serv­er, the http response of the serv­er could optionally include a Last-Modified http head­er to tell the brows­er when the file was last modi­fied. The next time your vis­itor reloads your page, their brows­er will asks the web serv­er if the file has changed since the brows­er’s last request by including a If-Modified-Since http head­er. If it is changed the brows­er will download the newest file, if not the brows­er will use the file in it’s cache.

etag

It works roughly the same as the Last-Modified http head­er but in­stead of telling the brows­er when it is last modi­fied it tags the file with a generated checksum val­ue.

This is used because sometimes—but not very of­ten, at least I hope it’s not—the serv­er’s clock gets messed up, that would mean the cache is not accurate anymore. That is why etag is much more pre­ferred, the key is unique, less likely to be messed up by errors like mis­adjust time.

etag howev­er is also plagued by it’s unique identi­fi­er, since the key is unique, sites that is hosted with mul­ti­ple serv­er or us­ing cdn will not match etag generated from an­oth­er serv­er, thus rendering it use­less. It is rec­ommended that etag be removed by the Yahoo! Exceptional Performance team.

Expires

While checking with the web serv­er to see if a file has changed is better than getting the file it­self, there is still a need to check ev­ery time viewers reloads the page. This is when Expires http head­er starts to look like a better al­ternative to etag & Last-Modified.

What Expires does is tell the brows­er when it sends a file that the file can be used over and over again until a certain time. The brows­er will use the cache ver­sion of the file ev­ery time your viewers reloads the page un­less it expires.

set it up

The in­struction is for Apache, if you are us­ing iis seek elsewhere for in­struction on how to set it up. While you can write the exact cache con­trol head­er to all the files you want cached, I pre­fer us­ing mod_expires to spec­ify the cache rule.

Before we proceed make sure your Apache serv­er have mod_expires & mod_headers in­stalled and loaded.

cache files by exten­sion

This method tar­gets files with the spec­i­fied exten­sion, while that can be very simple to perform and under­stand it has it’s own down­side. For one it requires a file exten­sion.

 
  <FilesMatch "\.(html|htm)$"> 
    Expires A3600 
  </FilesMatch> 

The code above ba­sically matches ev­ery file with the exten­sion .html or .htm and adds an expiry date, 3600 sec­onds af­ter access (A). To tar­get oth­er file exten­sion just change the exten­sion and modify the expiry date as you see fit.

cache files by mime type

Tar­geting the mime type is much accurate than file exten­sion as the exten­sion can be eas­ily changed but this method requires you to remember setting the correct mime type. Changes like gzipping the file can change the file’s mime type and with­out prop­erly defining the mime type, the file will not be tar­geted.

 
  ExpiresByType text/html A3600 

Just like the code before, this code ba­sically spec­i­fies that the mime type text/html expires 3600 sec­onds af­ter access (A).

By enabling ExpiresActive, we can spec­ify the expiry date in a more plain en­glish like syntax. In­stead of defining it A3600 it can be written like access plus 1 hour which means the same.

result

If ev­ery­thing went smoothly, the resul­ting http head­er should look some­thing like this.

 
  HTTP/1.1 200 OK 
  Date: Tue, 17 Nov 2009 10:00:00 GMT 
  Server: Apache/2.2.13 
  Expires: Tue, 17 Nov 2009 10:00:00 GMT 
  Connection: close 
  Content-Type: text/html 
  Content-Encoding: gzip 
  Content-Length: 4326 

source

The article se­ries is sourced from var­ious articles including, Website Opti­mi­sa­tion Measure by Kroc Camen, Website Opti­mi­sa­tion Measure se­ries articles by Jens Meiert, Opti­mizing openSpaceBook by Ryan Doherty, Exceptional Performance by Exceptional Performance team from Yahoo and 14 Rules for Faster-Loading Web Sites by Steve Soud­ers.

Seperation of functionality from struc­ture & presentation. A lot of web devel­op­ers have not be­gun to ap­preciate this new paradigm. Javascript were once used for rel­atively simple tasks like form val­idation or ani­mation, now it is responsible for some site’s core functionality.

Un­obtrusive javascript means to pro­vide graceful degradation so that websites works even with javascript disabled. Nowadays more viewers surf the web with javascript disabled, thanks to No­Script. It speeds up brows­ing speed and increase secu­rity by blocking third party scripts, not to mention saving bandwidth¹.

reduce http requests

When it comes to http requests, it is not a mat­ter of speed but rather about the lim­ited number of si­multane­ous connection. You see usu­ally, browsers can han­dle up to two si­multane­ous http requests, in oth­er words the more files you have the brows­er to download the slower the loading time becomes because no mat­ter how fast of a connection you have, your brows­er still will only process two at a time.

The eas­i­est way to reduce http requests is to combine files of the same type into one file. This can be applied to your css, javascript and im­age. css & javascript can be eas­ily combined by hand, all you need to do is copy and paste ev­ery­thing into one big file. As for im­ages, there is a great guide by A List Apart.

This can also be achieved by reduc­ing the number of objects in the con­tent of your page. This becomes more of a judge­ment call for web mas­ters. If your page usu­ally have a lot of objects embedded try splitting them into a number of pages, this pro­vides better view­ing expe­ri­ence while reduc­ing the amount of object that needs to be request by the brows­er. If it is a blog, try reduc­ing the number of articles per page, if most post have lots of objects there is no shame in showing one post per page.

gzip

Gzip what ev­er you can. This saves bandwidth for both you and the viewers. Ev­ery­thing from text files to fonts can be gziped and serve if you prop­erly de­fine the file type. You can man­ually Gzip ev­ery file before serving or you can use Apache mod_deflate to automat­ically com­press and serve with the correct file type.

To manually gzip your files just run gzip [filename] and you will get your new com­pressed file with a .gz exten­sion. Before you serve them you need to tell Apache what type of file is it and that the file is com­pressed before it serves to your viewers by defining it in your .htaccess file.

By adding AddType [filetype] [fileextension] will tell Apache what type of file the com­pressed files are and by adding AddEncoding gzip [fileextension] will tell Apache that the file is com­pressed us­ing Gzip. Af­ter that all you need to do is link them from your html doc­u­ment like you link them uncom­pressed.

To automat­ically serve your files com­pressed by Apache just add AddOutputFilterByType DEFLATE [filetype] into your .htaccess file. Once Apache see that line of code, it will serve all files that is of the type you spec­i­fied com­pressed.

images

Us­ing im­age is the eas­i­est way to show what we web devel­op­er wants the viewers to see, but ev­ery im­age file is an object for the web brows­er to load. Im­ages are normally big in compari­son to your text files, even if you combine the im­age file used in your css, you would still end up with a rel­atively large file. There are sev­eral ways that you can make your vis­itor’s expe­ri­ence much more pleas­ant.

Opti­mise Im­age

Opti­mis­ing your im­age will reduce the size of your im­age while retain­ing your im­age quality. All imag­ing soft­ware out­puts inef­ficient im­ages that wastes val­uable bandwidth, sometimes a few hundreds of kilo­bytes. This means that viewers would be wast­ing their time downloading need­less information of the im­age and imag­ine if you serve ten im­ages, those kilo­bytes can shoot up to a few megabytes.

There are a lot of free im­age opti­mi­sa­tion ser­vices avail­able on the inter­net, the most popular one is Smush.it. There are also tools that you can use locally like pngcrush & jpegtran.

Width & Height

Have you ev­er been to a website where they have a lot of im­ages but the page is jump­ing all around as you read the con­tent? That is because the page’s im­ages have no width & height spec­i­fied. Not only is this annoying it also slows down rendering speed.

When you spec­ify the width & height on , your html doc­u­ment will allocate the space before the im­ages are loaded thus saving some rendering time in­stead of having to re­allocate the space when the im­ages are loaded.

By adding the width & height will also al­low readers that is reading your con­tent to be able to do so with­out dis­turbance. Un­less you have expe­ri­enced it your­self, you have no idea how annoying it is to read a para­graph half way and have to scroll down a lit­tle because the loaded im­age reflowed the doc­u­ment.

background im­age

Most websites use background im­ages for their background, it pro­vides much more flexibility than displaying a dull, one colour background—though that is not true anymore with css 3 but it is still not widely support­ed. While your vis­itor loads a sometimes huge background im­age, vis­itors will look at your website with­out the background im­age for a short pe­riod of time and one annoying thing is that the background im­age sometimes is the same colour as your text, rendering it impos­sible to read with­out the background im­age.

That is why web devel­op­ers need to always spec­ify a background colour that closely resembles your background im­age. Sometimes when you have a bad web host­ing ser­vice the im­age might not even load and that can greatly af­fect the viewers expe­ri­ence in your website.

For me I pre­fer to let css han­dle all my rendering. There is abolutely no im­ages used to render ev­ery part of this website. With css 3, ev­ery­thing gra­di­ent to ani­mation can be done us­ing css 3.

bye bye ie 6

This is not a new top­ic, my site for one is not support­ing ie 6. For person­al website, this hardly can be a diffi­cult choice but when it comes to co­op­erate websites, it can be partic­ularly diffi­cult. As much as we like to ignore ie 6, it is likely here to stay for some time, but bare in mind that a number of large website like MobileMe has already tak­en the first step to drop support for that ar­cha­ic brows­er, the trend is inevitable.

I cannot be­gin ex­press­ing my discomfort—I know I’m sugarcoat­ing it—with ie 6. The lack of support for devel­op­ers to perform any de­cent css se­lection means that you can’t tar­get any el­e­ment with­out ID or class. There is also rendering bugs that have haunt devel­op­ers for years and force devel­op­er to produce ugly hacks that is eas­ily bro­ken.

Only by forc­ing ie 6 to upgrade, will we see the end of it.

source

The article se­ries is sourced from var­ious articles including, Website Opti­mi­sa­tion Measure by Kroc Camen, Website Opti­mi­sa­tion Measure se­ries articles by Jens Meiert, Opti­mizing openSpaceBook by Ryan Doherty, Exceptional Performance by Exceptional Performance team from Yahoo and 14 Rules for Faster-Loading Web Sites by Steve Soud­ers.

Many would think that getting good seo rank­ing is differ­ent from opti­mis­ing their website to run faster. Con­trary to this be­lieve, with good web opti­mi­sa­tion your website’s seo rank­ing will improve it­self, by then it would seem that hiring some­one to improve your seo rank­ing would be redun­dant. Here are, in my opin­ion, some opti­mi­sa­tion tips that you should fol­low.

get your markups right

This cannot be more important than any­thing and yet very of­ten it is ignored. The rule is to cre­ate a well struc­tured markup that de­notes the structural se­mantics of the web page.

why?

A good markup pro­vides the meaning to the doc­u­ment, getting your html markup is your most important task. Your doc­u­ment can have the most beautiful styles in the world but it means noth­ing when it is poorly struc­tured.

Having a good markup also saves a lot of time in maintain­ing it. Trust me, if it is a good markup, you will not see the need to change it anymore. A well struc­tured html markup will stand the test of time.

header

The <head> el­e­ment is one of the most abuse el­e­ment in a html doc­u­ment. Web mas­ters very of­ten shove ev­ery single crap they can into the <head> el­e­ment. Putting all these <meta> el­e­ments will bring you no where while cre­ating a messy and ugly code.

omit needless code

Favicon

 
      <link rel="shortcut icon" href="/favicon.ico" /> 
    

There is absolutely no need for that line of code. Favicon has become a standard and it is support­ed by all browsers. By default most brows­er will automat­ically re­trieve the favicon that is prop­erly named and placed.

Even if for some bizarre rea­son you want to put your favicon some place else, you can always rewrite the url in your .htaccess file.

seo Keywords

seo keywords will bring your site to no where. Paying some­one to “improve” your site’s seo rank­ing is almost the same as paying your dog to clean your house, it does no good. Having a good markup howev­er, will.

stylesheet

css is used to style the presentation se­mantics, it renders your markup into your desired struc­ture, so it is vital for your viewers to load the file as soon as pos­sible. Let’s face it, view­ing the html markup with­out any styling isn’t very appealing to the viewers.

That is why stylesheets should be placed first, preferably af­ter the <title> el­e­ment but if you re­ally want to have the css file load first you can place it on top of <title>. The rest of the <link> el­e­ment can be place af­ter the stylesheet.

body

The part where struc­ture your con­tent. It is what the viewers will see from their web brows­er. The con­tents are normally dynam­ic so it is important to write cleanly indented markups so that it is readable.

While normal viewers will nev­er look at the html source, there are many web designers—including my­self—like to read. Having a readable markup will not only encour­age oth­ers to read the source it also al­lows you to read them as well ¹.

Code is beautiful, code it­self can be po­et­ry.

scripts

Javascript’s job is to enhance the viewer’s expe­ri­ence when vis­iting the site by defining the functionality, not to replace the web page’s struc­ture or presentation. As such, javascript should be placed at the bottom of <body> because the site should look the same even with­out javascript.

This is because when browsers load the javascript file, ev­ery­thing stops. If your javascript file is huge—I don’t see any rea­son why it should be—loading the script will halt ev­ery­thing, giving an unresponsive feel to the viewers.

An­oth­er rea­son is that javascript cannot change the html dom until the html doc­u­ment has loaded. Plac­ing the script at the top will not make it run any faster than plac­ing them at the bottom.

source

The article se­ries is sourced from var­ious articles including, Website Opti­mi­sa­tion Measure by Kroc Camen, Website Opti­mi­sa­tion Measure se­ries articles by Jens Meiert, Opti­mizing openSpaceBook by Ryan Doherty, Exceptional Performance by Exceptional Performance team from Yahoo and 14 Rules for Faster-Loading Web Sites by Steve Soud­ers.

A hack is any­thing that has the po­tential to fail disas­trously each time some­thing changes expectedly.

kroc camen

For the longest time, web devel­op­ers have been struggling to get their websites to render just as any oth­er brows­er would. The lim­i­tations of Inter­net Explorer made it almost impos­sible un­less some sort of work arounds or ie spe­cif­ic hacks that forces ie to play nice but as Kroc Camen pointed out “A hack is any­thing that has the po­tential to fail disas­trously each time some­thing changes expectedly.”

[…] Google Chrome Frame running as a plu­gin has dou­bled the attach area for malware and ma­licious scripts. This is not a risk we would rec­ommend our friends and fam­i­lies take.

The thing is Microsoft’s frus­tratingly slow adoption of the web standards forced people to come up with not so el­egant solutions. It is also true that ie plu­gins would cre­ate an additional opportunity for hacker to exploit but for Microsoft to say the plu­gin is not safe is not help­ing at all. The prob­lem was cre­ated by Microsoft in the first place and in­stead of fixing the prob­lem, they tell people that the people who offer a solution—not a very good one, but a solution nonethe­less—that they didn’t do a good job covering the mess Microsoft cre­ated in the first place. Google wouldn’t need to come up with Google Chrome Frame if ie renders new standards prop­erly, because as much as we like to stop support­ing ie, big compa­nies cannot ignore 65% of the people who surfs the web us­ing ie.

The performance of the scripting en­g­ine has lit­tle discernible impact on today’s web pages, […] a faster JavaScript en­g­ine would offer no practical val­ue to end users.

Web standard is only a fraction of ie’s prob­lem, we’ve seen a massive improve­ments on javascript capa­bilities on all major brows­er to bring near native speed javascript performance so that much more so­phis­ticated web applications can be cre­ated. Microsoft’s response to these trends? “The performance of the scripting en­g­ine has lit­tle discernible impact on today’s web pages, […] a faster JavaScript en­g­ine would offer no practical val­ue to end users.”.

I am not go­ing to com­ment on how ignorant that com­ment was but I will say that if Microsoft con­tinues to ignore the open standard and keep push­ing pro­pri­etary technology like Silver­light, they will only con­tinue to see it’s brows­er’s mar­ket share plummet.

As much as we all like to de­stroy ie, what needs to be done is to stop support­ing an­cient browsers like ie 6 and force us­er to switch to up to date, standard compli­ant browsers.

dtd pro­vides a list of the el­e­ments, attributes, com­ments, notes, and entities con­tained in the doc­u­ment. It also indicates their relation­ship to one an­oth­er with­in the doc­u­ment. In oth­er words, a dtd is the grammar of an xml or html doc­u­ment, it tells applications like your brows­er or on­line code val­idator what type of markup you’ve coded into the page.

Syntax

Be­low is the doctype for xhtml 1.0 Strict & the syntax for doctype for compari­son.

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

 
  <!DOCTYPE [Top Element] [Availability] "[Registration]//[Organization]//[Type] [Label]//[Language]" "[URL]"> 

1. [Top Element] – Indicates the top lev­el el­e­ment type de­clared in the dtd.
2. [Availability] – Indicates if the identi­fi­er is a publicly ac­cessible object (PUBLIC) or a system resource (SYSTEM) such as a local file or url. (x)html dtds are spec­i­fied by PUBLIC identi­fiers.
3. [Registration] – Indicated by ei­ther a “+” or “-”. A plus symbol indicates that the orga­ni­zation name that fol­lows is iso-reg­is­tered. A mi­nus sign indicates the orga­ni­zation name is not reg­is­tered. The ietf & w3c are not reg­is­tered iso orga­ni­zations and thus use a “-”.
4. [Organization] – This is the “Owner­ID”—a unique label indicating the name of the entity or orga­ni­zation responsible for the cre­ation and/or main­tenance of the artifact (dtd, etc.) be­ing ref­er­enced by the doctype. The ietf & w3c are the two orig­inating orga­ni­zations of the of­ficial (x)html dtds.
5. [Type] – This is the “Public Text Class”—the type of object be­ing ref­er­enced. There are many differ­ent keywords pos­sible here, but in the case of an (x)html dtd, it is “dtd”.
6. [Label] – This is the “Public Text De­scription”—a unique de­scriptive name for the public text that is be­ing ref­er­enced. If the public text changes for any rea­son, a new Public Text De­scription string should be cre­ated for it.
7. [Language] – This is the “Public Text Language”—the nat­ural language encoding system used in the cre­ation of the ref­er­enced object. It is written as an iso 639 language code. (x)html dtds are usu­ally written in En­glish—“EN”.
8. [URL] – This is the optional explicit url to the dtd be­ing ref­er­enced.

why specify a doctype?

Because it de­fines which ver­sion of (x)html your doc­u­ment is actually us­ing, and this is a crit­ical piece of information needed by browsers or oth­er tools pro­cess­ing the doc­u­ment. Tools such as the markup val­idator needs it to check the syntax of your (x)html or they won’t know what doc­u­ment it is checking.

Most importantly, modern browsers need that to determine the type of doc­u­ment it is dealing with. When a brows­er don’t know what doc­u­ment it is dealing with, it will fallback to quirks mode, browsers will at­tempt to guess at which language the doc­u­ment was written in and pages will be rendered much slower com­pared to the standard mode and of­ten in error.

doctype list

The list of doctype are much more than what we normally use, w3c have the full list of doctype avail­able to use. Some of the ones we normally use are.

html 4.01

Strict, Transitional & Frameset.

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

xhtml 1.0

Strict, Transitional & Frameset.

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

xhtml 1.1

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

html 5

HTML 5’s doctype have a much simpler syntax.

 
  <!DOCTYPE html> 

I know there are many free flash players that plays mp3, this is just to show that we can have a flash player with­out in­stalling one. This mp3 player is similar to the Gmail player but it also works on non-Google websites. The player has vol­ume con­trols and it auto-de­tects the duration of the mu­sic file so people know how long the song will last, best of all it has no Google banding whatsoev­er on the player. Not only will we go discuss the way to stream mp3 us­ing a flash player but also to cre­ate a standard complaint code for embedding flash.

I first found an article on the var­ious flash player that can be used to stream mp3 and embed them in your website including the Google player. As nice as those players are, I refuse to use them because they uses the <embed> tag which is not a valid tag of the xhtml spec­ification¹. Then again, 99% of the flash embedding code uses the <embed> tag, while some re-codes the embedding code like CommonCraft. The <embed> el­e­ment was cre­ated by Netscape as their method of embedding plug-ins and players in web pages. It’s not part of the xhtml spec­ification, and while some browsers oth­er than Netscape support it, it’s not standards-compli­ant.

Though I didn’t like the embedding code, I liked the Google Read­er player and so I searched for more information about the player. I found the long ver­sion of embedding the player:

 
  <object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/
shockwave/cabs/flash/swflash.cab" width="500px" height="27px" align="middle"> 
    <param name="allowScriptAccess" value="always" /> 
    <param name="movie" value="http://www.google.com/reader/ui/3247397568-audio-player.swf" /> 
    <param name="FlashVars" value="audioUrl=URL" /> 
    <param name="quality" value="best" /> 
    <param name="bgcolor" value="#EEEEEE" /> 
    <param name="scale" value="noScale" /> 
    <param name="wmode" value="opaque" /> 
    <param name="salign" value="TL" /> 
    <embed id="Player" scale="noScale" salign="TL" 
    src="http://www.google.com/reader/ui/3247397568-audio-player.swf?audioUrl=URL" 
    wmode="opaque" quality="best" bgcolor="#EEEEEE" width="500px" height="27px" name="Player" 
    align="middle" allowScriptAccess="always" 
    type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/
go/getflashplayer" /> 
  </object> 

Again it uses the <embed> code, and so I needed a way to make a leaner, standards-compli­ant method of embedding Flash. The answer? Flash Sa­tay. It ba­sically teaches how to transform that ugly code to a standard compli­ant code with the same capa­bility thus giving us this².

 
  <object type="application/x-shockwave-flash" width="500px" height="27px"> 
    <param name="allowScriptAccess" value="always" /> 
    <param name="movie" value="http://www.google.com/reader/ui/3247397568-audio-player.swf" /> 
    <param name="FlashVars" value="audioUrl=URL" /> 
    <param name="quality" value="best" /> 
    <param name="wmode" value="opaque" /> 
  </object> 

All you need to do is replace url with the url to your mp3 file and you’re set. The code is much neater and it performs just the same.