Graphics can add a real nice touch to a website . . . or they can slow it down so much that no one will wait for the page to load! Webmasters designing new pages are forced to examine the pros and cons of web page graphics. As you plan your latest website project, will you use graphics or not, and if so, should you? Here we will look at both sides of the equation.

It all boils down to functionality. If you are selling paintings on your website, you will obviously need graphics, no two ways about it. The same goes for nearly any kind of product that could be featured graphically, such as books, stereos, etc. People like to see what they are buying, so you pretty much need to have pictures for these items.

However, if you are going to put photos of your products up, you should consider making them thumbnails for faster loading and make them clickable. Clients can then choose which one they want to see in more detail and click to see the full version. Since they know what they are doing, they won’t mind waiting a little extra time to see the product graphics.

Apart from purely practical use, should you use graphics on your website? That depends on what kind of graphics you want to use. You need to make the page easy to read and relatively fast to load. This rules out most giant graphics, such as photographic backgrounds, unless they are absolutely necessary.

If you do decide to use some reasonably sized graphics, you should try to limit the number per page. While a cute logo is fine, having little animals all over your sidebars and buttons can be not only distracting, but it also looks pretty unprofessional. Cluttering up your site with too many graphics is not generally a good idea, it gives a bad impression and if you are trying to sell something, an amateur look is not the way to go, no matter how fun it is.

When deciding whether or not to add graphics to your website, you should consider whether or not it adds quality to the page. Do you feel that your website will be represented through the graphic you are considering? Will it help sell your products? Is it going to convince the customer to stay when they might have thought about clicking away? If you find yourself saying yes to any one of the above questions, you have a good reason to be putting graphics on your site. Otherwise, you should probably forget about it and stick to a more simplistic look.

The decision of whether or not to display graphics on your website really is a personal one, but it can make all the difference in terms of sales and how many visitors actually stay on the page! If it takes too long to load graphics that you simply must have, try lowering the resolution a bit for faster loading times. Remember that people are impatient and will simply click away to another site if yours is too slow or too cluttered.

• 0 Comments

Flash-based sites have been a craze since the past few years, and as Macromedia compiles more and more great features into Flash, we can only predict there will be more and more flash sites around the Internet. However, Flash based sites have been disputed to be bloated and unnecessary. Where exactly do we draw the line? Here’s a simple breakdown.

The good:

Interactivity

Flash’s Actionscript opens up a vast field of possibilities. Programmers and designers have used Flash to create interactve features ranging from very lively feedback forms to attractive Flash-based games. This whole new level of interactivity will always leave visitors coming back for more.

A standardized site

With Flash, you do not have to worry about cross-browser compatibility. No more woes over how a certain css code displays differently in Internet Explorer, Firefox and Opera. When you position your site elements in Flash, they will always appear as they are as long as the user has Flash Player installed.

Better expression through animation

In Flash, one can make use of its animating features to convey a message in a much more efficient and effective way. Flash is a lightweight option for animation because it is vector based (and hence smaller file sizes) as opposed to real “movie files” that are raster based and hence much larger in size.

The bad and the ugly:

The Flash player

People have to download the Flash player in advance before they can view Flash movies, so by using Flash your visitor range will decrease considerably because not everyone will be willing to download the Flash player just to view your site. You’ll also have to put in additional work in redirecting the user to the Flash download page if he or she doesn’t have the player installed.

Site optimization

If your content was presented in Flash, most search engines wouldn’t be able to index your content. Hence, you will not be able to rank well in search engines and there will be less traffic heading to your site.

Loading time

Users have to wait longer than usual to load Flash content compared to regular text and images, and some visitors might just lose their patience and click the Back button. The longer your Flash takes to load, the more you risk losing visitors.

The best way to go is to use Flash only when you absolutely need the interactivity and motion that comes with it. Otherwise, use a mixture of Flash and HTML or use pure text if your site is purely to present simple textual and graphical information.

• 0 Comments

Peter B. was an out-of-work PHP developer looking for contract work in early 2005. A recruiter he’d worked with in the past emailed him some information regarding a possible position. Reading the job description, Peter thought he’d be a good fit, so he submitted his resume and got a response via email a few days later.

The hiring manager described their typical process; Peter would have to answer a screening question to determine his skill level, and if his answer was satisfactory, they’d schedule a face-to-face interview. With a little trepidation, Peter said he was ready for the question. He was concerned that it could be about a complex topic that he wasn’t very familiar with. A few hours later, an email arrived with the subject “SCREENING QUESTION,” flagged with high importance.

His mouse hovering over the email, he expected to open it and have to answer “on a PB349 microprocessor, if memory address 0xa9f00c contains a MOV instruction to memory address 0×8ad9da, what is the magnetic force dispensed by a 64KB memory module for the next 600 instructions? You have thirty seconds.”

Peter took a deep breath and clicked on the email. Here is the exact question he was asked: “Describe what concatenation is, how it applies to PHP, and how you’ve used it in the past.”

Peter was surprised. It was a question that anyone with any basic exposure to any modern programming language could answer. It would’ve been harder to describe what multiplication was and how he’d used it in the past.

Still, he wanted to show that he understood the concept, so he played along. He typed up a detailed response.

Concatenation is the process to sequentially join multiple pieces of data, usually literal strings with non-string-literal data (most commonly, variables or other literals). The concatenation operator varies from language to language. Javascript, for example, overloads the plus-sign (+) as it is both the concatenation operator as well as the arithmetic addition operator. PHP uses the period (.) as the concatenation operator.

String concatenation is often used in PHP to build a string of HTML for output to the client (browser). This is common in prodecural-based PHP code. However, I should note that oftentimes, that using concatenation for HTML generation is inefficient or can be better served by some other design pattern – particulary if the developer is using concatention during an echo operation (in this case, comma-separating the tokens is faster).

Another common use for string concatenation is the generation of dynamic SQL queries. For example, if I had a CMS that was to pull all articles written by a certain user, the code might look something like this

<?php
$sql = “SELECT article_id, article_body FROM Articles WHERE author_id = ” . $User->getID() . ” ORDER BY article_date DESC”;
?>

As you can see, the above code combines three tokens to generate a complete SQL query.

1. A SQL fragment
2. The user’s ID as pulled from a custom User object
3. A SQL fragment

SQL queries are rarely generated without some sort of dynamic data to alter their structure, so this is a very common task that I’ve used in just about every web application I’ve written. Some other simple examples include cookie generation, error message generation, email headers, and dynamic URL construction.

I hope this sufficiently explains concatenation in general, how it relates to PHP, and my experience with using this basic operator.

Peter sent the email and got a phone call a few days later.

Peter: Hello?
Lisa: Hi, Peter? This is Lisa from Concatcorp.
Peter: Oh, hi! Good to hear from you! I hope you have news about the job.
Lisa: Well, yes, but…
Peter: Yes?
Lisa: We’re going to offer the position to another candidate.
Peter: I see… may I ask why? I thought I did a pretty thorough job answering the screening question…
Lisa: Well, that’s just it. The problem is that they think your answer was too good. They think you plagiarized it. I’m sorry.

It was then that Peter realized he was probably better off without that job.

• 0 Comments

“The word hack doesn’t really have 69 different meanings”, according to MIT hacker Phil Agre. “In fact, hack has only one meaning, an extremely subtle and profound one which defies articulation. Which connotation is implied by a given use of the word depends in similarly profound ways on the context. Similar remarks apply to a couple of other hacker words, most notably random.”

Hacking might be characterized as ‘an appropriate application of ingenuity’. Whether the result is a quick-and-dirty patchwork job or a carefully crafted work of art, you have to admire the cleverness that went into it.

An important secondary meaning of hack is ‘a creative practical joke’. This kind of hack is easier to explain to non-hackers than the programming kind. Of course, some hacks have both natures, but here are some examples of pure practical jokes that illustrate the hacking spirit:

In 1961, students from Caltech (California Institute of Technology, in Pasadena) hacked the Rose Bowl football game. One student posed as a reporter and ‘interviewed’ the director of the University of Washington card stunts (such stunts involve people in the stands who hold up colored cards to make pictures). The reporter learned exactly how the stunts were operated, and also that the director would be out to dinner later.

While the director was eating, the students (who called themselves the ‘Fiendish Fourteen’) picked a lock and stole a blank direction sheet for the card stunts. They then had a printer run off 2300 copies of the blank. The next day they picked the lock again and stole the master plans for the stunts — large sheets of graph paper colored in with the stunt pictures. Using these as a guide, they made new instructions for three of the stunts on the duplicated blanks. Finally, they broke in once more, replacing the stolen master plans and substituting the stack of diddled instruction sheets for the original set.

The result was that three of the pictures were totally different. Instead of ‘WASHINGTON’, the word ‘CALTECH’ was flashed. Another stunt showed the word ‘HUSKIES’, the Washington nickname, but spelled it backwards. And what was supposed to have been a picture of a husky instead showed a beaver. (Both Caltech and MIT use the beaver — nature’s engineer — as a mascot.)

After the game, the Washington faculty athletic representative said: “Some thought it ingenious; others were indignant.” The Washington student body president remarked: “No hard feelings, but at the time it was unbelievable. We were amazed.”

This is now considered a classic hack, particularly because revising the direction sheets constituted a form of programming.

Here is another classic hack:

On November 20, 1982, MIT hacked the Harvard-Yale football game. Just after Harvard’s second touchdown against Yale, in the first quarter, a small black ball popped up out of the ground at the 40-yard line, and grew bigger, and bigger, and bigger. The letters ‘MIT’ appeared all over the ball. As the players and officials stood around gawking, the ball grew to six feet in diameter and then burst with a bang and a cloud of white smoke.

The Boston Globe later reported: “If you want to know the truth, MIT won The Game.”

The prank had taken weeks of careful planning by members of MIT’s Delta Kappa Epsilon fraternity. The device consisted of a weather balloon, a hydraulic ram powered by Freon gas to lift it out of the ground, and a vacuum-cleaner motor to inflate it. They made eight separate expeditions to Harvard Stadium between 1 and 5 AM, locating an unused 110-volt circuit in the stadium and running buried wires from the stadium circuit to the 40-yard line, where they buried the balloon device. When the time came to activate the device, two fraternity members had merely to flip a circuit breaker and push a plug into an outlet.

This stunt had all the earmarks of a perfect hack: surprise, publicity, the ingenious use of technology, safety, and harmlessness. The use of manual control allowed the prank to be timed so as not to disrupt the game (it was set off between plays, so the outcome of the game would not be unduly affected). The perpetrators had even thoughtfully attached a note to the balloon explaining that the device was not dangerous and contained no explosives.

Harvard president Derek Bok commented: “They have an awful lot of clever people down there at MIT, and they did it again.” President Paul E. Gray of MIT said: “There is absolutely no truth to the rumor that I had anything to do with it, but I wish there were.”

The hacks above are verifiable history; they can be proved to have happened. Many other classic-hack stories from MIT and elsewhere, though retold as history, have the characteristics of what Jan Brunvand has called ‘urban folklore’ Perhaps the best known of these is the legend of the infamous trolley-car hack, an alleged incident in which engineering students are said to have welded a trolley car to its tracks with thermite. Numerous versions of this have been recorded from the 1940s to the present, most set at MIT but at least one very detailed version set at CMU.

Brian Leibowitz has researched MIT hacks both real and mythical extensively; the interested reader is referred to his delightful pictorial compendium The Journal of the Institute for Hacks, Tomfoolery, and Pranks (MIT Museum, 1990; ISBN 0-917027-03-5). The Institute has a World Wide Web page at http://hacks.mit.edu/Hacks/Gallery.html. There is a sequel entitled Is This The Way To Baker House?. The Caltech Alumni Association has published two similar books titled Legends of Caltech and More Legends of Caltech.

Here is a story about one of the classic computer hacks:

Back in the mid-1970s, several of the system support staff at Motorola discovered a relatively simple way to crack system security on the Xerox CP-V timesharing system. Through a simple programming strategy, it was possible for a user program to trick the system into running a portion of the program in ‘master mode’ (supervisor state), in which memory protection does not apply. The program could then poke a large value into its ‘privilege level’ byte (normally write-protected) and could then proceed to bypass all levels of security within the file-management system, patch the system monitor, and do numerous other interesting things. In short, the barn door was wide open.

Motorola quite properly reported this problem to Xerox via an official ‘level 1 SIDR’ (a bug report with an intended urgency of ‘needs to be fixed yesterday’). Because the text of each SIDR was entered into a database that could be viewed by quite a number of people, Motorola followed the approved procedure: they simply reported the problem as ‘Security SIDR’, and attached all of the necessary documentation, ways-to-reproduce, etc.

The CP-V people at Xerox sat on their thumbs; they either didn’t realize the severity of the problem, or didn’t assign the necessary operating-system-staff resources to develop and distribute an official patch.

Months passed. The Motorola guys pestered their Xerox field-support rep, to no avail. Finally they decided to take direct action, to demonstrate to Xerox management just how easily the system could be cracked and just how thoroughly the security safeguards could be subverted.

They dug around in the operating-system listings and devised a thoroughly devilish set of patches. These patches were then incorporated into a pair of programs called ‘Robin Hood’ and ‘Friar Tuck’. Robin Hood and Friar Tuck were designed to run as ‘ghost jobs’ (daemons, in Unix terminology); they would use the existing loophole to subvert system security, install the necessary patches, and then keep an eye on one another’s statuses in order to keep the system operator (in effect, the superuser) from aborting them.

One fine day, the system operator on the main CP-V software development system in El Segundo was surprised by a number of unusual phenomena. These included the following:

• Tape drives would rewind and dismount their tapes in the middle of a job.
• Disk drives would seek back and forth so rapidly that they would attempt to walk across the floor.
• The card-punch output device would occasionally start up of itself and punch a ‘lace card’ (card with all positions punched). These would usually jam in the punch.
• The console would print snide and insulting messages from Robin Hood to Friar Tuck, or vice versa.
• The Xerox card reader had two output stackers; it could be instructed to stack into A, stack into B, or stack into A (unless a card was unreadable, in which case the bad card was placed into stacker B). One of the patches installed by the ghosts added some code to the card-reader driver… after reading a card, it would flip over to the opposite stacker. As a result, card decks would divide themselves in half when they were read, leaving the operator to recollate them manually.

Naturally, the operator called in the operating-system developers. They found the bandit ghost jobs running, and killed them… and were once again surprised. When Robin Hood was gunned, the following sequence of events took place:

!X id1id1: Friar Tuck... I am under attack!  Pray save me!

id1: Off (aborted)

id2: Fear not, friend Robin!  I shall rout the Sheriff

     of Nottingham's men!

id1: Thank you, my good fellow!

Each ghost-job would detect the fact that the other had been killed, and would start a new copy of the recently slain program within a few milliseconds. The only way to kill both ghosts was to kill them simultaneously (very difficult) or to deliberately crash the system.

Finally, the system programmers did the latter — only to find that the bandits appeared once again when the system rebooted! It turned out that these two programs had patched the boot-time OS image (the kernel file, in Unix terms) and had added themselves to the list of programs that were to be started at boot time (this is similar to the way Windows viruses propagate).

The Robin Hood and Friar Tuck ghosts were finally eradicated when the system staff rebooted the system from a clean boot-tape and reinstalled the monitor. Not long thereafter, Xerox released a patch for this problem.

It is alleged that Xerox filed a complaint with Motorola’s management about the merry-prankster actions of the two employees in question. It is not recorded that any serious disciplinary action was taken against either of them.

Finally, here is a wonderful hack story for the new millennium:

1990’s addition to the hallowed tradition of April Fool RFCs was RFC 1149, A Standard for the Transmission of IP Datagrams on Avian Carriers. This sketched a method for transmitting IP packets via carrier pigeons.

Eleven years later, on 28 April 2001, the Bergen Linux User’s Group successfully demonstrated CPIP (Carrier Pigeon IP) between two Linux machines running on opposite sides of a small mountain in Bergen, Norway. Their network stack used printers to hex-dump packets onto paper, pigeons to transport the paper, and OCR software to read the dumps at the other end and feed them to the receiving machine’s network layer.

Here is the actual log of the ping command they successfully executed. Note the exceptional packet times.

Script started on Sat Apr 28 11:24:09 2001
vegard@gyversalen:~$ /sbin/ifconfig tun0
tun0      Link encap:Point-to-Point Protocol
          inet addr:10.0.3.2  P-t-P:10.0.3.1  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:150  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0
          RX bytes:88 (88.0 b)  TX bytes:168 (168.0 b)

vegard@gyversalen:~$ ping -i 450 10.0.3.1
PING 10.0.3.1 (10.0.3.1): 56 data bytes
64 bytes from 10.0.3.1: icmp_seq=0 ttl=255 time=6165731.1 ms
64 bytes from 10.0.3.1: icmp_seq=4 ttl=255 time=3211900.8 ms
64 bytes from 10.0.3.1: icmp_seq=2 ttl=255 time=5124922.8 ms
64 bytes from 10.0.3.1: icmp_seq=1 ttl=255 time=6388671.9 ms

— 10.0.3.1 ping statistics —
9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 3211900.8/5222806.6/6388671.9 ms
vegard@gyversalen:~$ exit

Script done on Sat Apr 28 14:14:28 2001

A web page documenting the event, with pictures, is at http://www.blug.linux.no/rfc1149/. In the finest Internet tradition, all software involved was open-source; the custom parts are available for download from the site.

While all acknowledged the magnitude of this achievement, some debate ensued over whether BLUG’s implementation was properly conformant to the RFC. It seems they had not used the duct tape specified in 1149 to attach messages to pigeon legs, but instead employed other methods less objectionable to the pigeons. The debate was properly resolved when it was pointed out that the duct-tape specification was not prefixed by a MUST, and was thus a recommendation rather than a requirement.

The perpetrators finished their preliminary writeup in this wise: “Now, we’re waiting for someone to write other implementations, so that we can do interoperability tests, and maybe we finally can get the RFC into the standards track… ”.

The logical next step should be an implementation of RFC2549.

• 1 Comment

It’s another day on the Internet and yet another form of ad monetization has reared its ugly head.

You Tube recently launched its InVideo advertising solution to a resounding dull clang of dissatisfaction from the exuberant masses who consume hours of content on the beloved Web site.

It’s not hard to see why. And in the interests of full disclosure, I do work in online advertising, yet I think it’s really kind of hard to love this solution.

Don’t get me wrong. For some, loving advertising is like loving tax preparation. YouTube’s solution isn’t easy to understand in the context of how it’s used with content. The relative context of application, if you will.

Specifically, hearing a lo-fi video defense of a pop star is bad enough, but when it’s shrouded with a slick transition to the ad message, it all seems a brash and out-of-place marriage of elements.

This blight-on-blight online advertising solution is only the most recent. There have been many others before, and rest assured there will be more in the future.

It makes me wonder why we keep coming up with the same solutions to monetize this relatively new medium. Can’t we get a little more creative? Or are we destined to a downward spiral of repeating the same advertising model on everything we do?

Make the logo bigger. Stick a special offer in at the end. Repeat. Yes, these forms of advertising are familiar, like a comfy old chair, but old and comfy can get stinky after a while.

In their book, “New World, New Mind” Robert Ornstein and Paul Ehrlich point out, “Human judgment and humanity’s ability to deal with the consequences of its creations lags behind its ability to create.”

Bad times at any company’s online solutions division lie ahead.

We constantly trying to innovate, yet we don’t slow down our minds (or our development cycles) to really contemplate the impact of our work. It’s a truly vicious circle.

We develop measurement criteria in the same way. Often, these two crimes combine to provide poor ad solutions and mishandled performance valuations.

In a competitive industry, yes, time is money. But ignorance wastes time, money, and a user’s interest in your brand. I’d say the last is much more costly.

Damning as that may sound, it’s been true for quite a while. Did anybody ever think the floating rich media ad would dominate the online advertising industry forever?

For that matter, the lovely and controversial You-Tubian solution for integrating advertising into its spectacle of video content shares the same future.

Lest we forget, the practice of inserting :15 spots before and after video content that floods the news became the new hair extension for a thinning and expensive media market. Truly, to think an online spot can be included in overall television rating points (TRPs), regardless of screen size and format, is unfathomable.

But as bad as it sounds, there’s hope for an industry known for interrupting viewers’ valuable time (and being the spawn of Satan).

There are ways in which we can rethink this whole ad thing. First, we must ask ourselves a few questions: Why must an ad follow a traditional story arc? Why do we need to assume users must understand everything they see? Why do we need comedy to make a viewer remember an ad? Why can’t the user have several available options and interactions?

—

By  Dorian Sweet

• 0 Comments

The text Diagnosing SVN by Tom Lord describes a series of problems with the development of Subversion. There are a number of interesting insights on programming in general in that article. (Rebuttal here).
For the record, I am a big fan of Subversion. We use it at Flux Studios with generally very few problems. I also run a “server” at home, i.e. an external hard drive with a subversion setup, for all my personal work. Even though I am the only one accessing these files, I find the ability to back track changes and the general safe feeling of my work being committed is really worth it.
Compared to the only other version control systems that I have real experience with, CVS and Visual SourceSafe, it is really outstanding.

• 0 Comments

In no particular order 55 reasons for me to do “tableless” websites using valid XHTML for markup, CSS for layout and Flash sparingly, only as an ingredient. By tableless I mean avoiding tables (or a tagsoup of unnecessary divs substituting table trs and tds) for layout purposes and aiming towards as semantic markup as possible. Some of the reasons are “over HTML”, some “over Flash full monty” and some over both.

I know this topic has been discussed a plenty, I just needed to reaffirm myself :)

Here we go:

1. You can get free links from showcase sites like zengarden, stylegala, cssimport or cssbeauty
2. You don’t have to spend extra thought and time deciding on styling the mark up of your document (upper- or lowercase, quotes or no quotes on attributes)
3. You don’t need to spend extra thought on which tags should be closed and which can (or should) be left open
4. You “help” the search engines to deliver more relevant content using semantic markup
5. You can save in bandwidth costs and visitors will see them faster by making slimmer pages
6. It’s going to be easier for you to switch to XHTML 2.0 which will give you more semantic tools
7. Once you’ve practised enough, coding pages becomes a whole lot simpler and faster than any table/tr/td tagsoup
8. When the coding is faster you can spend more time on thinking about the user experience
9. Thinking about semantics of a document helps you to make design and information architecture decisions
10. You can quickly make a dummy site to test your sites information architecture and append a look and feel later with only minor code changes
11. You can do the design after most of the backend is done which will help your client (or boss) to think realistically about how much work is still needed
12. It’s possible to link directly to your content pages (compared to Flash)
13. browser controls like text-size and back and forward buttons work (compared to Flash)
14. Redesigns and realigns over the whole site are simpler
15. it’s simpler to make small last minute changes to your designs
16. Clean markup makes it easier or even unnecessary to build a CMS
17. Clean markup makes it easier for another developer to jump on board
18. You can make the backend almost totally independently from the frontend design, by completely different person
19. You have plenty of ways to play with the markup trying to optimize for search engines, without affecting visible layout
20. You have total control on print layouts of your pages
21. Your sites are automatically accessible to all kinds of browsers
22. Promoting web standards will help your work in the future, not having to code differently to each browser
23. With all elemets closed you mark up look cleaner
24. Well-formed code ensures your site works in more browsers
25. Well-formed code would help browser coders to spend more time on useful features than rendering engines that try to understand borken code
26. Your website will work in future browsers
27. Your website works in mobile (and other new) devices
28. You learn the basics of XML which has many other uses
29. CSS files are saved in browser cache for fast retrieval and less bandwidth use
30. Your documents are easy to convert back and forth another format using XSLT
31. Thinking semantics makes you think more about the content
32. Learning semantics makes you appreciate organization and write your other documents (even emails) in more organized way
33. You can write new technologies in your CV or portfolio
34. Modern browsers render a valid document faster
35. You feel better about yourself when you are making sites “the right way”
36. They are doing it: Dan Cederholm, Jeffrey Zeldman, Jason Santa Maria, Shaun Inman, Cameron Moll, Douglas Bowman, Dave Shea…
37. You will belong in a “movement”, make good contacts etc.
38. You learn to appreciate newer browsers which makes for more competition and later for better browsers
39. Blink tag is gone
40. Strict coding makes you learn to see mistakes quicker
41. You can aim to making some money writing a book about it
42. There are more job opportunities if you know these new ways
43. You learn better to understand how a browser works
44. You can use hacks and techniques with cool names like “be nice to Opera”
45. you start to care more about metadata, document and character types
46. With more people making slimmer pages, the amount of data moving in the whole web will be smaller and all connections faster
47. XHTML has a cooler name than HTML
48. There are more people thinking about the advantages and disadvantages and coding tricks of XHTML which makes for a bigger learning forum
49. You can use basically same markup template for many different websites
50. Learning to read and write it fast makes it possible to use cheaper tools (notepad)
51. Google knows this:
    • 4,380,000 xhtml better than html > 4,370,000 html better than xhtml
    • 206 “xhtml is better than html” > 87 “html is better than xhtml”
    • 2,130,000 xhtml sucks < 10,300,000 html sucks
52. When all browsers start to understand the correct MIME-type (xml), you don’t have to convert all your websites from html, just to switch to correct MIME
53. By more people using xhtml you ensure that in the future IE will need to understand the correct MIME-type
54. Accessibility is enforced with requiring Alt attribute for images
55. There just aren’t this many reasons to use HTML or entirely Flash instead

• 59 Comments

This represents, to my opinion the “Web 2.0 Concept”. As always; “A photo is worth a million words”.

I’ve downloaded this photo some months ago, for the funny & laughs section, but I think it is more appropriate to represent the “Web 2.0 Concept”. I don’t know who’s that car is,so I can’t credit a single person for the photo. It was an anonymous posting somewhere.

Comments are welcome!

• 0 Comments