While I tend to agree with Misunderstanding #1, I do find it VERY convenient to be able to see a "printable version". Why? I use FireFox with the Platypus/GreaseMonkey extension. Viewing the printer-friendly page and then invoking Platypus lets me selectively remove sections that I may not want to print. I can (somewhat) tailor what gets printed saving me lots of print time and ink. Platypus can be used on "normal" pages also, but it's certainly easier on the printer-friendly versions. Of course, I suspect that I'm FAR from the norm on this.

This would, of course, be a non-issue if only FireFox's Print Preview screen had Platypus capabilities....

I absolutely agree with that Jim.

Such a shame! I can't read Google Blogoscoped on my mobile. There is an error that says "not enough memory". I guess there is too much text on the homepage. Nonetheless I am surprised, I thought the memory is quite sufficient (40 mb). My site, onreact.com and Google do work allright. My site working fine did indeed suprise me when I first visited it on my mobile. It uses merely XHTML strict with no special CSS for other applications and has absolute positioned layers.

Did you try Opera Mini? It's quite good in doing the job of pre-compressing...

I'm sure many have already seen it, but there was just recently a posting about CSS questions answered by Håkon Wium Lie, Chief Technology Officer of Opera and one of the two original creators of CSS. (http://interviews.slashdot.org/article.pl?sid=06/06/23/1443203)

Some very interesting questions and answers about CSS.

Fantastic! I love Opera, it works perfectly.

One real advantage of separate mobile content is the small data size. My network charges me per kilobyte of data transferred and so I would prefer to browse the mobile versions even if my phone is capable of displaying the normal large-screen version. I usually even use Google's helpful WML and xHTML "translator" because its good at stripping out unnecessary content.

Excellent post Philp! Lots to think about here. Thanks for throwing it all out there.

Eugene, but if tackled right these can be mere network/ rendering issues. For example, Opera Mini uses a proxy to pre-convert everything into smaller stuff. The Google proxy on the other hand splits up pages into sub-pages. I think that's the great thing about HTML as layout neutral format, that it doesn't necessarily tell the user agent how to treat it. For example, in a Google search result, the whole page is compressed into a single snippet...

Your story on Digg:
http://digg.com/design/9_Ways_to_Misunderstand_Web_Standards
Cool!

(digg this guys)

I suspect XForms will be ready in Firefox before 2014, if the current state of their XForms module (http://www.mozilla.org/projects/xforms/) is any indication.

Also, you can use tools render your standard, accessible markup into Ajaxian Javascript stuff on the fly, either in the server (http://chiba.sourceforge.net) or in the browser (http://www.formfaces.com). There are other intermediate solutions as well, such as the http://www.formsplayer.com plugin for IE.

XForms is designed for accessibility, and is on the W3C's Web Accessibility Dynamic Content roadmap. So, take a look at the trajectory of XForms and decide where you want to intercept.

Ironically enough, i'm reading this blog post on Netscape 4.78 on a Solaris computer. This website is pretty broken up but still definately legible (except names in the forum b/c the icons tile). However, a few sites i've been to have done really poorly. Wikipedia even managed to crash the browser.

anway, about the points: i agree with everything except the mobile web. I have a cost per byte plan and every little bit helps, so if I really need to do something online I use google's mobile converter. Until unlimited data transfer becomes a widespread reality, I at least want the option to have a smaller, low bandwidth version of websites.

I most agree with the alt tag point. It's as if developers don't care about the meaning of the alt tag anymore – now it's just a way to show tooltips, and in text based browsers, the intended recipients of the alt tag's information, most web pages look ridiculous. I think the key concepts here are "suppliment" and "compliment" – what does the image do? Google's logo, for instance, suppliments the page's heading, while caption photos compliment headlines. Another one I love is a photo with a caption and identical alt text so you see the same thing twice.

To be standards-compliant, though, any image that needs no ALT text should have an empty-string ALT instead of omitting the attribute altogether, like ALT="". This has the added benefit of getting some text-mode browsers to ignore the image altogether instead of putting in something messy like [IMAGE] or the filename.

Regarding the printable-page issue, one thing that was alluded to is the fact that many sites (especially online newspapers and magazines) like to divide articles up into lots of bite-size chunks, forcing you to keep following "Next" links, while the printable version is more conveniently all together in one piece. Does anybody know why they insist on breaking up articles that way? It's really annoying; I prefer scrolling in one document over continually going to new ones.

Dan: The reason articles are broken up into multiple pages is to create more advertisement views. It's a necessary evil that comes with getting so much content for free.

I have to conquer with Leigh: XForms is indeed a reality today. XForms can, but does not have to run on the client. Server-side XForms works very well. This is something we use every day for applications that go into production.

The Ajax-based open source implementation of XForms I use is PresentationServer (bias: I am not only developing applications with PresentationServer, but also working on the code of PresentationServer itself). For more see: http://www.orbeon.com/

In a sense, this reminds me the days when people were saying that XSLT was not practical because it was not implemented on browser. This was around 1998. Since then XSLT became widely used... on the server-side. And today very large sites like eBay use XSLT. Just like XSLT, server-side implementation of XForms are robust and are today a solution for form-based web applications.

Alex

QUOTE:
when your image is a mere illustration to a point you're repeating elsewhere in the text, there's no need at all to use the alt text.

Absolutely wrong. There is much benefit to be had, most notably for search engines. In general I find your info to be incomplete and semi-accurate but I'll spare you a point by point breakdown. I'd just add that the tenth way to misunderstand web standards is to listen to you.

No mention of the star hack for IE?

.box {
   width: 580px;
}

* html .box {
   width: 600px;
}

you made the front page of digg

http://www.digg.com

Have to completely disagree with you on #5. Using the CSS Zen Garden as your example is a total cop out and a bad umbrella to place CSS designs under. The reason for so many classes in the markup of the garden html is so that advanced graphic techniques and image replacement can be used, with no limits on creativity.

By no means is that how the markup for CSS driven sites looks like. And I don't see how CSS doesn't completely separate content from style. View a modern standards based site sans-css and tell me where the style is.

Forget CSS Hacks. Completely. If you have to present differenty declarations to Internet Explorer, use conditional comments.

What an excellent article! I've been wanting to read another one of these for ages, and this is just what I was looking for. I agree with just about every point you've made, and you've reminded me of some of the things I should be remebering when designing new sites.

Thanks a lot.

Great article! This is a nice, well-reasoned short list of the big problems with taking too shallow of a perspective on web standards. I could _maybe_ quibble on minor sub-points, but not on any of the over-riding ideas!

Hello,

Just a quick word,
You have been selected as one of The Blog Blogs Honorary Blogs
Congratulations and enjoy your Honour.
From: the-blogblog.blogspot.com

You shouldn't be using CSS hacks *at all*. Using presentational markup is preferable to doing so – presentational markup will continue to work on any browser that supports your doctype. However, CSS hacks, as many IE7 beta testers have probably found out already, tend to disappear over time.

I've never needed to use a single CSS hack over the course of my web development career. This paid off, big-time, when all of my sites worked as-is in IE7 and Bon Echo. All of the people who used hacks not only need to spend time correcting their sites, but also need to figure out how to do the same thing the *right* way this time around. That means spending the effort of solving the same problem twice.

As a standards enthusiast, I believe many of your explanations to be inaccurate, incomplete, and misleading. You make some good points, however, the breakdown you provide for each point does not support your original thought very well.

To all new web designer/developers emerging into standards based web design, please be wary of the countless misleading articles written by "professionals" or "standards advocates".

Read, read, and read some more to get a better understanding of standards, accessibility, and usability, rather than relying on one article as the final word.

One point you make is really true:

   If I'd have to make a bet, I'd say creating an inaccessible website
   with CSS is 10 times as fast as doing the same with table layout.

Anecdotally, the most frequently used button on my web browser
is "Zap Style Sheets" (Thanks, Jesse!!) Far too many web sites
are terribly cluttered, and use tiny unreadable fonts.

And this is one reason you are wrong about separate print pages:
frequently they are far more accessible than either the CSS page
at any font magnification or the "Zapped" version.

And fwiw, another bugaboo is inappropriate fixed-width fields:
the human-factors experts say that text is most readable at 55-65
characters per line; far too many pages give me 200-character
lines (and a few (the new Slashdot!) give me 15-character lines).
PAGE LAYOUT SHOULD NOT ASSUME THE READER'S
SCREEN SIZE, FONTS, AND BROWSER LAYOUTS ARE
EXACTLY THE SAME AS YOURS!!!!

You know!important IS supported by IE in recent builds, right? Namely the version that came with SP2?

I don't agree with "Misunderstanding #3". If you are using the web browser Links for example, you might want to know what images there are on the website and to be able to download them. So also alt-texts like "W3C logo" for the image at the top of your post are important.

From Misunderstanding #3: "when your image is a mere illustration to a point you're repeating elsewhere in the text, there's no need at all to use the alt text."

I totally disagree.

While you, as the designer, or you, as the sighted person, may know it's redundant, others (particularly blind people) that are using screen readers may not. By making a decision to not include ALT tags for some images, you are effectively making decisions for people that have no choice. Instead of being so arrogant by saying that we know what's best, why not just give the information and let people decide for themselves?

Misunderstanding #0: CSS, HTML, XHTML are *no* standards. W3C publishes recommendations and drafts, and some *do* have flaws.

There's a very good reason to supply an "Easy Printing" page: if you don't, readers (almost none of whom have a clue about CSS, let alone media-dependent stylesheets) will assume that you're just not providing one; and since they don't want to bother printing multiple pages, and don't want to waste ink printing out all the ancillary stuff on the pages... why, they just won't print it at all, and certainly aren't going to read it all on screen. Bye.

In other words, a printable page has become a user-expected de facto standard.

Also, you conflate an easy-printing page with a long single-page format; many sites offer both. They're not the same thing.

Also, the word "she" is no more a gender-neutral pronoun than "he" is. In fact, "he" is more neutral because we're so used to it that it's semi-invisible. (Yes, I know you think that's the problem you're trying to address...) My point? Whenever I see someone using "she" as a generic pronoun, I know I'm dealing with someone whose brain has been rotted out by political correctness... which, in fact, is a close cousin of web-coding purism.

What a great articles – this is a keeper – thanks. I especially appreciated #4 and would like to hear a bit more. You may have many spin offs from this one.

Ellen Weber from BrainBasedBusiness

In my mind all this comes down to percentages and how important is it for things to display the way you intended them to be. You can make a fixed width layout but forget about it if that layout is wider then the the persons screen, you can forget about accessibility and not make alt tags and leave out the people that cant see, you can fill a site with AJAX but you are eliminating people with javascript turned off and older browsers. I dont care what most html accessability people say about it, I like the number 97% on people on the internet have the flash player. Everything will look right in any browser that has it the player, I can write function to deal with accessibility, I can make frames to deal with the back buttoon and I can embed the flash file inside of the html with swfobject so that google can read the contents of the page. Done deal, not to mention it will look way cooler then anything you guys come up with.

This was really nice to read. I happen to be struggling with CSS, scriptaculous and AJAX at this time. I think CSS has 2 major features: saves bandwidth, makes designing a unitary look and feel easy, and improves overall design. I does not yet help on semantic layout, and gives you a chance to totally confuse users over navigation and links.
[Signature removed. -Philipp]

I'm not exactly sure how I found your page, but I felt like throwing my 2c worth in. I have mixed feelings about your opinions/statements of fact. Correctly structured html/xhtml and css unquestionably a) improve user experiance, b)make linking to things like "print page", "mobile page" etc very east, c) make the whole idea of separation of design/layout from content pretty simple with or without a separate "templating" engine.

I'm not a particularly big fan of AJAX, it tends to create more problems (because of it's reliance on javascript, and the differences in compatibility with various browsers) than it solves.

I'm not a particularly big fan of javascript in general for the same reasons as above, but then again, carefully coded javascript can be compatible with most browsers, and can be compliant with w3c standards.

I am a big fan of standards. Something like the standards developed by the w3c are developed with the input of many, many talented and smart individuals, as opposed to by a single company or individual. If more folks would pay attention to the standards as written and accepted, there would be way less of the types of problems you discuss to begin with. Included in this group of folks would not only be web developers/consultants, etc, but almost more importantly, the browser developers. Instead of spending the time required to adhere to many of the standards as written it's been much easier for all of them to launch a somewhat stable product by "hacking" around difficult problems/issues. Same goes for the web developers, it's often easier to come up with a "hack" that more or less works with all browsers, than to create technically correct code which would also work with all browsers, without the need to sacrifice any advanced capabilities, features, etc.

...chris

www.hradil.us

For some more detail on how to work with Standards in the Mobile Web, take a look at what we're doing in the W3C Mobile Web Best Practices (http://www.w3.org/TR/mobile-bp/) working group. This document describes 60 ways to work within existing Web standards to provide great Mobile Web user experiences.

Dan Appelquist
Chair, Mobile Web Best Practices Working Group

Try this Philip
http://www22.porsche.com/usa/accessoriesandservices/porschefinancialservices/paymentestimator/?ifp=RT%3d1151359386988%26model%3d997420%26price%3d126320.00%26optionen%3dIAT.M404.M249.FG1.M425%26geartype%3d-1

Dan:
> By no means is that how the
> markup for CSS driven sites looks like.

I didn't mean that – my implication was that no one can create HTML like CSS Zen garden, so we all need a template system for redesigns.

Concerned:
> Read, read, and read some more to get a better understanding of
> standards, accessibility, and usability, rather than relying on
> one article as the final word.

Absolutely agreed. No one should rely on anything I (or any single other person) says as the final word, but always read up on many other sources. If you have specific criticism on my article I'm happy to discuss it.

Ignoranctow:
> You know!important IS supported by IE in
> recent builds, right?

A perfect illustration how CSS hacks can be dangerous, as they become outdated quickly...

Friend:
> While you, as the designer, or you, as
> the sighted person, may know it's redundant,
> others (particularly blind people) that are
> using screen readers may not. By making a
> decision to not include ALT tags for some
> images, you are effectively making
> decisions for people that have no choice.

I always use alt attributes (there is no such thing as "alt tags"), however, I'm using *empty* ones when I think this fits best. As you may know from using tools like Lynx, an empty alt text will be interpreted as "author knows what she's doing, let's get rid of this." Only when you create invalid HTML – the alt attribute is *mandatory* on the img element – do tools have reason to assume the author didn't know what she's doing, and they can then take measurements like displaying [image] in its place.

John Bokma:
> Misunderstanding #0: CSS, HTML, XHTML are *no* standards.
> W3C publishes recommendations and drafts, and some *do*
> have flaws.

You are right. I actually included this info in the original introduction to the article, but I later got rid of the intro (as well as the conclusion).

William Rogers:
> There's a very good reason to supply
> an "Easy Printing" page: if you don't,
> readers (...) will assume that you're just
> not providing one

Unless the browser tells them or *shows* them that there's a print-ready page near, which was part of my point. I don't think browsers today handle print pages very well. Again, read what I said on this, and you'll see we agree on this point... "The good thing about these pages is that the user gets an instant impression of what the print-out will look like. Of course, the right way to do this would be to serve a separate stylesheet for medium print, and if the browser does it right, it will show the visitor a print preview."

> Also, the word "she" is no more a gender-neutral pronoun
> than "he" is. In fact, "he" is more neutral because we're
> so used to it that it's semi-invisible.

If you read my articles you'll see I sometimes use "he" and sometimes "she", as I agree she isn't neutral as well. Hopefully the mixture is.

Sander:
> So also alt-texts like "W3C logo" for the image
> at the top of your post are important.

No, that's what the title attribute is for. When I am using a text-to-speech engine I don't want to hear "W3C logo". It disrupts the flow and adds nothing important to the point. This is not true for all images obviously, some images have very reasonable and needed alt text.

ellenweber:
> What a great articles – this is a keeper – thanks. I especially appreciated
> #4 and would like to hear a bit more.

Well, when I say that it's faster to create inaccessible sites with CSS I'm referring to a bunch of things:
- You can quickly lower contrasts in forms to the point the text becomes hard to read
- You can quickly decrease the font size
- You can quickly decrease font contrasts
- Remove link underlines
- etc.

Most (not all) of these things were possible with plain vanilla layout-based HTML3.2, CSS simply speeds up the process. Look at web standards site A List Apart, which I think is cool, but which also has a tiny, tiny font, making it very inaccessible to all users who don't know how to increase the font size. Even for those who do, it's slightly annoying. http://www.alistapart.com/articles/prettyaccessibleforms

Note that I'm not saying decreasing font size, lowering contrasts or removing underlines is always bad – it totally depends on the context and the actual parameters used.

Tyler:
> I like the number 97% on people on the internet
> have the flash player.

Agreed, this is a real number to work with, pragmatically. But also keep in mind future uses (maybe the mobile web becomes much more important?), uses that are only in low percentages due to the inaccessible nature of large parts of the web, and also the Googlebot who doesn't understand Flash well (the bot can render it, but not in meaningful ways, and if you use external XML files for Flash content on multi-language sites, that content is completely lost).

Christopher J. Hradil:
> Correctly structured html/xhtml and css
> unquestionably a) improve user experiance,
> b)make linking to things like "print page",
> "mobile page" etc very east, c) make the whole
> idea of separation of design/layout from content
> pretty simple with or without a separate "templating" engine.

Agreed! Instead of saying "all things are bad about web standards" I was actually trying to say "not *all* things are perfect with the current adoption of web standards." I think we hear a lot about how cool & great web standards are, but we rarely hear negative issues; so I was trying to cover that for a change. If you see my posts on HTML or CSS newsgroups you can see how I work with web standards for a long time, and I go to presentations by the W3C with great interest, and I'm also a big fan of the first half of Tim Berners-Lee's book on Weaving the Web (the 2nd half, on the other hand, didn't convince me – it wasn't as well structured, it wasn't drawing from experience as much, and it didn't come across as clear as the first half).

Elias:
> Try this Philip
> www22.porsche.com/usa/accesso

Just a note that I'm not working with the Porsche site anymore. I don't even know how many pages still validate as XHTML1 Strict, though we had a CM system in place that would automatically sent alerts when pages were invalid. Not those iframe pages tho. The Porsche layout was actually put on a layout grid, meaning everything had to be exactly positioned on a certain 7-pixels grid, but that's another story :)

"We Need an Alternative Mobile Web on Top of the Existing Desktop Web" – I'm not sure about this issue. I think the smaller screens of mobile devices, and the likelihood that users will want to do stuff quicker (plus the difficulty of doing things quicker via typical mobile device interfaces) mean that, whilst XHTML is fine, a dedicated mobile version, with absolutely nothing on the page other than what needs to be there, might be nicer for people.

Not sure though, as I don't have any significant experience with mobile browsing myself, let alone know what other people have found.

"With CSS We're Completely Separating Content and Layout" – we're only not doing that due to the current limitations of CSS. And if we hadn't been held back by Netscape 4 and Internet Explorer's CSS bugs for the last 8 years, we might have managed to get CSS improved. Give it time, I say.

"CSS Hacks Are Always Superior" – necessary evil? Don't use them at all. Internet Explorer is the only relevant browser left with significant bugs, and it comes with its own, standards-compliant way of working around them: conditional comments. Add a stylesheet for each version of IE you need to support (if separate ones are necessary, they aren't always depending on your bugs). Write your main stylesheet according to the standards, then work around IE bugs in your IE stylesheets. This has the added advantage of letting you know just how long you're spending supporting buggy browsers.

As a web designer I try to prioritize my involvement with the web by always asking, "what is my or my client's ultimate goal?"

I have no feeling for "pure" W3C standards because it doesn't address any goals I can immediately think of...and in that feeling I'm probably very well represented throughout the Internet. Even Google says their code is non-compliant because it renders quicker that way.

Your article has solidified what I continue to believe. A table based website with a superficial half-assed style sheet to create site-wide changes to fonts is the best possible "current" form of communication on the Internet. It works on all browsers, it can be indexed by every search engine, and most importantly...is given priority by Google! http://tinyurl.com/l292f

Bottom line. The client's goal is to sell products and services. This is not W3C compliant.

> Even Google says their code is non-compliant
> because it renders quicker that way.

Where did they say that? And you believe them? I don't.

> Your article has solidified what I continue to believe.
> A table based website with a superficial half-assed
> style sheet to create site-wide changes to fonts is
> the best possible "current" form of communication on the Internet.

Either you're sarcastic, or my article's point was too easy to miss.

> It works on all browsers, it can be indexed by
> every search engine, and most importantly...is given
> priority by Google!

It's a myth that Google prefers invalid HTML, if that's what you're saying.

> The client's goal is to sell products and services. This
> is not W3C compliant.

I'd argue that W3C compliancy is part of it, for starters because the client also wants to have a lean website to save money on development (there are many more positive effects, too).

> Even Google says their code is non-compliant
> because it renders quicker that way.

>Where did they say that? And you believe them? I don't.

"In more general terms, what do you think is the relationship between Google and the W3C? Do you think it would be important for Google to e.g. be concerned about valid HTML? (Philipp Lenssen)

"I like the W3C a lot; if they didn’t exist, someone would have to invent them. :) People sometimes ask whether Google should boost (or penalize) for valid (or invalid) HTML. There are plenty of clean, perfectly validating sites, but also lots of good information on sloppy, hand-coded pages that don’t validate. Google’s home page doesn’t validate and that’s mostly by design to save precious bytes. Will the world end because Google doesn’t put quotes around color attributes? No, and it makes the page load faster. :) Eric Brewer wrote a page while at Inktomi that claimed 40% of HTML pages had syntax errors. We can’t throw out 40% of the web on the principle that sites should validate; we have to take the web as it is and try to make it useful to searchers, so Google’s index parsing is pretty forgiving." (Matt Cutts)
http://blogoscoped.com/archive/2005-11-17-n52.html

> Your article has solidified what I continue to believe.
> A table based website with a superficial half-assed
> style sheet to create site-wide changes to fonts is
> the best possible "current" form of communication on the Internet.

>Either you're sarcastic, or my article's point was too easy to miss.

I summarized your article for myself perhaps inaccurately. "CSS is not cross browser compatible without an excessive amount of work, hacks, and knowledge. Tables on the other hand work on everything." Perhaps I am missing your point. I'm always open to clarification.
Sorry about the NY humor. It's always mistaken for sarcasm.

>It's a myth that Google prefers invalid HTML, if that's what you're saying.
Well, that's the way it looks. (see above link(s))

> The client's goal is to sell products and services. This
> is not W3C compliant.

>I'd argue that W3C compliancy is part of it, for starters because the client >also wants to have a lean website to save money on development (there >are many more positive effects, too).

You may have me there. You're developing sites for very well recognized clients with enourmous budgets and ongoing timelines. I'm doing sites for $5K and under in a week. Once again it comes down to putting the client's goal first. They want cheap sites and results. So I get them first page of the SERPS for long tail conversion keywords and "outdated" code. Seems to work for me as they never come back with complaints.

I think most clients don't care because they rely on you for technical details. For one of the last large sites we converted – ~70,000 totally invalid, HTML3.2ish + heavy-JS pages + no meaningful CSS at all – the client would never have figured there's anything wrong. We had to "sell" W3C compatibility, but the client thought the arguments were convincing, so we got the budget for this. Of course W3C compatibility was just one piece of the puzzle. We also had to convince the absolute need for a CMS. We then chose the CMS based on how well it handles W3C recommendations, among many other factors of course (it ended up being a nice C# + MS-SQL + XML -> XSLT -> XHTML system, Windows platform more or less a prerequisite).

As for why tables are worse than CSS-based layouts, I think there's a variety of reasons, some I hinted at in my article, though admittedly my article did not focus on the merits of CSS (but rather the dangers of it):

- with tables, you don't have full control over linearizing the content. For example, you may wish to have a longer navigation to the left, yet you wish to make your site accessible to text-to-speech clients; so when you put the navigation into the left cell, it will always come first. With CSS, you can put the navigation on the left but still have it follow the content, e.g. I do that with this blog. We also did that at Porsche http://www.porsche.com/usa/models/boxster/boxster/indetail/design/

- tables often render slower or show variations in width while the page loads, as the full table content needs to be rendered to calculate all table widths

- tables can add nasty "lasagna" complexity through interdependent cells – you wanna have "ravioli" complexity, you know, be able to pick out one thing from the whole without destroying the rest.

- tables merge the layout with the content, which isn't good for a variety of reasons, one is maintenance, the other is media-independence (e.g. a different screen and print layout may be wanted)

Of course, there are perfectly valid reasons for using tables, always when you want to display tabular data! I always use this rule of thumb: can I find a rows or column heading for this? E.g. can I title the rows with "name" and "age", or "user photo" and "user details"? If so, it's probably actually tabular data. If not, div's might be better....

Great Post!

I get it!
It's clear it could eliminate many hours of time consuming updates.

Probably very important for a Web 2.0 "Internet domination" LAMP (linux,apache,mysql,php/perl) website.

lets throw it all in and follow the wild dreams of Ted Nelson...the father of "hypertext" :)
google his name for more....hehe