XML Sucks?

I searched the Internet and found something funny about XML. As we all know that we've discussed about XML before. We said it's the ultimate solution to problems brought by HTML. Well, some guys don't think so.

Generally speaking, though XML brings us tremedous benefits over HTML, inevitably it has got some defacts. The sum up list is listed below:

• XmlIsTooComplex for what it does.
• It's too hard for programs to parse and too verbose and unreadable for humans to write.
• The benefits of "everyone is using XML, so we should too" are usually outweighed by the costs of time, training and mistakes involved in understanding it.
• Because it's increasingly used for data interchange, it is promoted as a data storage model. XML is only a data encoding format.
• or just comments wrapped around data. Too much comments and symbols.
• , when they could just be comments instead.
• Encourages non-relational data structures
  • ie. Data is not even in 1st normal form let alone 5th.
• Poor OnceAndOnlyOnce syntax factoring
• It's a poor copy of EssExpressions
• It is ExtremelyInterstrangled.
• Perhaps worst of all too many programmers don't understand the need for data description languages with broad support.
• Transformations, even identity transforms, result in changes to format (whitespace, attribute ordering, attribute quoting, whitespace around attributes, newlines). These problems can make "diff"ing the XML source very difficult.

I picked up several for details (affirmative for XML is in italics. Opposite is in normal form.):

XML is too hard for programs to parse and too verbose and unwritable for humans.

It's not too hard for programs to parse - XML is a subset of SGML, which is well understood and well implemented, and because it's more rigorous than HTML it's easier to parse than HTML, which is a solved problem. It's not too hard for humans, by a long shot; a well-written DTD is a cakewalk to write in.

Tedious rather than hard. It takes more time and code to extract the information you want from XML than it does to have the information formatted in flat files. Parsing flat files is easier than processing DOM unless tools are provided.

Well, this is certainly true. You get an old argument of the virtues of (new thingy) over (old thingy). People thought HTML was silly in the light of Gopher, which was flat text, easier to write, edit and parse, and faster to transmit; over time they were shown to be incorrect (correction: over time they were shown different means serve different purposes). XML provides a mechanism for us to provide a parsable definition of document structure, which means that unlike CommaSeparatedValues or similar setups, the software doesn't have to know the document's structure ahead of time (given an XML parser; magic? Fact: xml is a document format; The use of DOM and IPC is the key to the success of XML (see SOAP). File space requirements matter less every day (tell that to a CPU designer, and he will laugh loud), and though not trivial, XPath and XSLT are important features over and above what CSV provides. For many applications it's overkill. So is sending readme.1st files in RTF.


The benefits of "everyone is using XML, so we should too" are usually outweighed by the costs of time, training and mistakes involved in understanding it.

What are those costs? Many people said this about HTML, but frankly it's just not that hard - commands go in angle brackets, slash means off, i for italic, hit save, you're done. Technical workers can handle that, and XML is no worse (if they need to write their own DTDs, that's a worse, but give that job to qualified staff. Training: everything takes training.

Some things more than others.

Most things more than XML.


Because XML is increasingly used for data interchange, it is too easily promoted as a data storage model. XML is only a data encoding format.

It's not designed as a data storage model, although models can be built on top of it. Compared to older ASN.1 (correction: ASN.1 is really only a language for defining protocols; actually the protocol defined in ASN.1 can use XML as its data transfer format) or GIOP, such XML models suck. Inherent limitations make them unsalvageable. But many folks confuse storage and exchange. XML must be concrete enough for light-weight programs to parse; the same data may be described in many ways, and different XML representations are suitable for different tasks, in opposition to the OnceAndOnlyOnce goal. In contrast the relational model and SQL use a canonical representation not favoring a particular task. In particular, many to many relationships are problematic in XML. We have gone back to the sequential text file model at the expense of the kind of abstraction we gained when moving from COBOL to SQL. If you really want to process data sequentially, COBOL is a far better tool than XSLT applied to XML - but sensible people use SQL. XML should just be used for transport, and there should be a canonical representation (schema) of the relational model. A simple subset of SQL could be implemented to operate on this representation to allow programmers to extract data. Imagine how much simpler life would be if instead of writing XML parsers, and editing enormous, complex and verbose text files by hand, we had a simple SQL-style interface. In fact - I think I'll write one! (that will be easier than XPath and XQuery?)
-- Tim Glover (ed SkipSailors)

Why do people insist on complaining that XML doesn't do this or XML doesn't do that, when XML is just supposed to be a data storage and transport mechanism? And now this comparison to COBOL? COBOL?!? Oy, vay!

XML isn't a database language per se. It is a means of expressing data in a tree structure. If you need flat storage of your data for relational reasons and you don't feel like parsing out an XML file full of relational data items then how about using something other than XML? Although any data can be stored in an XML format; it's just a matter of designing the storage translation in and out. XML reliably transports the stored data for you .

XML is a means of storing data in a tree structure and can express relationships. The XML community try to push it far too far. XML databases are a silly idea. XSLT is a silly idea. When you start embedding Java in XML a la Cocoon you know you've gone completely bonkers. I have another problem, XML has to be processed by a computer program eventually, be it xslt, java, whatever. Because XML is very concrete and highly non-canonical it introduces a very strong coupling between the actual representation chosen and the processing program, to which I object. You cannot change your XML DTD to optimize a particular task without having to rewrite all your existing programs. I don't think this has really hit home yet - but it will. It is going to cause BIG problems. SQL solves this problem by providing an abstract interface to the data. My comparison with COBOL was with XSLT, a programming language written in XML for XML, not with XML itself. They are very similar - XML elements correspond to sequential file record types. XML attributes correspond to COBOL data division templates (conceptually at any rate. COBOL is very concrete in its layout of data attributes). COBOL has the great advantage over XSLT that it provides a very clean separation of program from data. In XSLT these are hopelessly confused, which causes much of the difficulty in reading and understanding it. Thanks for engaging in this with me - I find it a useful and constructive discussion.

-- Tim


XML is not a good basis for developing data models. It is not a shortcoming of XML, rather a problem that engineers pick the wrong tool for the job so often. Don't use a screwdriver as a crowbar.

_____________________________


To sum up, though XML is not a new technique, the usage of it is still controversial. Because it's flexibility and power, this technique has been applied to multiple areas for data transportation, storage and manupulation. It shows great potential to replace techniques such as SQL and flat files. However, when we try to apply XML as a universial solution, it shows great defacts--after all, XML wasn't designed to do those. It's so powerful that people almost forget what it is for at the first place. So when we try to apply XML to our works, think clearly how well it would be used. If there is a more mature, convenience technique, don't use XML.

Pitfalls of SEO

Now SEO is somewhat popular--What's an easier way than to have your site on top of the two famous search engines? It's well known that search engine will notice your key words and add value to your site, and generally, if your key words appear many times in your site, your site will be deemed more important and relavant to the key words. Well, not for all cases. If you add key words in all your alt attributes, and use only key words for all your titles, Google or Yahoo may consider your behaviors as spamming, which will result in bad page ranking. So when you optimize your page for particular search engines, remember to read their guidelines first. Yahoo and Google all have guidelines for programmers. Know what behaviors they hates, and keep in mind to avoid those pit falls.

Part of Guidelines given by Google:

Quality guidelines - basic principles

• Make pages for users, not for search engines. Don't deceive your users or present different content to search engines than you display to users, which is commonly referred to as "cloaking."
• Avoid tricks intended to improve search engine rankings. A good rule of thumb is whether you'd feel comfortable explaining what you've done to a website that competes with you. Another useful test is to ask, "Does this help my users? Would I do this if search engines didn't exist?"
• Don't participate in link schemes designed to increase your site's ranking or PageRank. In particular, avoid links to web spammers or "bad neighborhoods" on the web, as your own ranking may be affected adversely by those links.
• Don't use unauthorized computer programs to submit pages, check rankings, etc. Such programs consume computing resources and violate our Terms of Service. Google does not recommend the use of products such as WebPosition Gold™ that send automatic or programmatic queries to Google.

Quality guidelines - specific guidelines

• Avoid hidden text or hidden links.
• Don't employ cloaking or sneaky redirects.
• Don't send automated queries to Google.
• Don't load pages with irrelevant words.
• Don't create multiple pages, subdomains, or domains with substantially duplicate content.
• Don't create pages that install viruses, trojans, or other badware.
• Avoid "doorway" pages created just for search engines, or other "cookie cutter" approaches such as affiliate programs with little or no original content.
• If your site participates in an affiliate program, make sure that your site adds value. Provide unique and relevant content that gives users a reason to visit your site first.

If a site doesn't meet our quality guidelines, it may be blocked from the index. If you determine that your site doesn't meet these guidelines, you can modify your site so that it does and request reinclusion.

Part of the Guinelines given by Yahoo:

Yahoo! strives to provide the best search experience on the Web by directing searchers to high-quality and relevant web content in response to a search query.

Pages Yahoo! Wants Included in its Index

• Original and unique content of genuine value
• Pages designed primarily for humans, with search engine considerations secondary
• Hyperlinks intended to help people find interesting, related content, when applicable
• Metadata (including title and description) that accurately describes the contents of a web page
• Good web design in general

Unfortunately, not all web pages contain information that is valuable to a user. Some pages are created deliberately to trick the search engine into offering inappropriate, redundant or poor-quality search results; this is often called "spam." Yahoo! does not want these pages in the index.

What Yahoo! Considers Unwanted
Some, but not all, examples of the more common types of content that Yahoo! does not want include:

• Pages that harm accuracy, diversity or relevance of search results
• Pages dedicated to directing the user to another page
• Pages that have substantially the same content as other pages
• Sites with numerous, unnecessary virtual hostnames
• Pages in great quantity, automatically generated or of little value
• Pages using methods to artificially inflate search engine ranking
• The use of text that is hidden from the user
• Pages that give the search engine different content than what the end-user sees
• Excessively cross-linking sites to inflate a site's apparent popularity
• Pages built primarily for the search engines
• Misuse of competitor names
• Multiple sites offering the same content
• Sites that use excessive pop-ups, interfering with user navigation
• Pages that seem deceptive, fraudulent or provide a poor user experience

YST's Content Quality Guidelines are designed to ensure that poor-quality pages do not degrade the user experience in any way. As with Yahoo!'s other guidelines, Yahoo! reserves the right, at its sole discretion, to take any and all action it deems appropriate to insure the quality of its index.

These guidelines are well hidden in Google and Yahoo's pages. Search their site carefully if you want them.

Referrence:

• Yahoo Guidelines
• Google Guidelines
  

DOM - Part Two - How to get a node easily?

Walk through in a more elegant way:

As we can see that walking through the DOM tree is actually very troublesome. If there are thousands of tags in your document, and what you need is just a particular one deep inside several nesting, I guess you'll simply give up if only method mentioned in first part in available. However, for programmers' convenience, DOM does have some support for fast access to particular nodes.

The first way is to get the element by its tag.So let's continue with our example. You want to access the element node B. The very simplest way is to directly jump to it. By the method document.getElementsByTagName you can construct an array of all tags B in the document and then go to one of them. Let's assume that this B is the first one in the document, then you can simply do

var x = document.getElementsByTagName('B')[0]

Or we can do it more directly, get an element by its name. The usage is even more straight forward:

var x = document.getElementById('hereweare');

Here if we've assign an element's id with "hereweare", the function will return the index to the element. Then we can manipulate the element in whatever way we want.

Example: Why we need DOM?

Actually, before DOM we can already access element quite easily in Javascript. Like in IE, we may just write:

void function hide(x)
{
x.style.visibility="hidden";
......
......
}

then call the function with element's id, like

hide("hello");

Then the element with Id "hello" will be manipulated with the statements in funciton hide().

However, it will easily generate problems. The value passed to the function is actually a string, not an index to element. It confuses programmer sometimes. In order to make the code more readable and standardized, we should adopt DOM instead of the method mentioned above. Actually, in Firefox we can only use DOM to access elements.

To make the function standardized, we need to modify it a little bit:

void function hide(name)
{
var x=getElementById(name);
x.style.visibility="hidden";
......
......
}

referrence: http://www.quirksmode.org/dom/intro.html

DOM - Part one

What's DOM?

The Document Object Model (DOM) is the model that describes how all elements in an HTML page, like input fields, images, paragraphs etc., are related to the topmost structure: the document itself. By calling the element by its proper DOM name, we can influence it.

The Level 1 DOM Recommendation has been developed by the W3C to provide any programming language with access to each part of an XML document. As long as you use the methods and properties that are part of the recommendation, it doesn't matter if you parse an XML document with VBScript, Perl or JavaScript. In each language you can read out whatever you like and make changes to the XML document itself.

As some of you might have guessed, this paragraph describes an ideal situation and differences (between browsers, for instance) do exist. Generally, however, they're far smaller than usual so that learning to use the W3C DOM in JavaScript will help you to learn using it in another programming language.

In a way HTML pages can be considered as XML documents. Therefore the Level 1 DOM will work fine on an HTML document, as long as the browser can handle the necessary scripts.

You can read out the text and attributes of every HTML tag in your document, you can delete tags and their content, you can even create new tags and insert them into the document so that you can really rewrite your pages on the fly, without a trip back to the server.

Because it is developed to offer access to and change every aspect of XML documents, the DOM has many possibilities that the average web developer will never need. For instance, you can use it to edit the comments in your HTML document, but I don't see any reason why you would want to do so. Similarly, there are sections of the DOM that deal with the DTD/Doctype, with DocumentFragments (tiny bits of a document) or the enigmatic CDATA. You won't need these parts of the DOM in your HTML pages, so I ignore them and concentrate instead on the things that you'll need in your daily work.

How DOM works?

In DOM, every element and its content was seen as nodes in a "document tree". Say we have codes like this:

<p>This is a paragraph<p>

You'll have a tree as below:

      <P> <-- element node
       |
       |
This is a paragraph >-- text node

And if we have:

<p>This is a <b>paragraph</b></p>

We'll have a tree like this:

        <P>
         |
   --------------
  |              |
This is a         <B>
                 |
                 |
              paragraph

We can see that if a tag is nested inside another, it will become a child node of its outer tag. So a DOM tree is formed by creating children nodes below parents as they are nested inside other nodes. By doing this we can guarantee that a well-formed web page will be mapped to definite, well-form DOM tree.


How to walk through a DOM tree?

Knowing the exact structure of the DOM tree, you can walk through it in search of the element you want to influence. For instance, assume the element node P has been stored in the variable x (later on I'll explain how you do this). Then if we want to access the BODY we do

x.parentNode

We take the parent node of x and do something with it. To reach the B node:

x.childNodes[1]

childNodes is an array that contains all children of the node x. Of course numbering starts at zero, so childNodes[0] is the text node 'This is a' and childNodes[1] is the element node B.

Two special cases: x.firstChild accesses the first child of x (the text node), while x.lastChild accesses the last child of x (the element node B).

So supposing the P is the first child of the body, which in turn is the first child of the document, you can reach the element node B by either of these commands:

document.firstChild.firstChild.lastChild;
document.firstChild.childNodes[0].lastChild;
document.firstChild.childNodes[0].childNodes[1];
etc.

or even (though it's a bit silly)

document.firstChild.childNodes[0].parentNode.firstChild.childNodes[1];

SSI -- Server Side Include

1.Introduction -- What is SSI

Server Side Includes or SSI is an easy server-side scripting language used almost exclusively for the web. As its name implies, its primary use is including the contents of a file into another, via a Web Server.
SSI is primarily used to "paste" the contents of one or more files into another. For example, a file (of any type, .htm, .txt, etc.) containing a daily quote, could be included into multiple SSI Enabled pages throughout a website, by placing the following code

<!--#include virtual="../quote.txt" -->

into the desired pages. With one change of the quote.txt file, pages including the snippet will display the latest daily quote. Server Side Includes are useful for including a common piece of code throughout a site, such as a navigation menu.
In order for a web server in a default configuration to recognise a SSI-enabled HTML file and therefore carry out these instructions, the file must end with the .shtml extension. SSI files can also end with .shtm but this depends on the servers ability to recognise the extension. It is possible to configure a web server to recognise any file with the .html file extension for server side include processing.

2. Basic Syntax and Directives

These are the most common SSI directives:

include
file or virtual
This is probably the most used SSI directive, allowing the content of one document to be included in another. The file or virtual parameters specify the file (HTML page, text file, script, etc) to be included. The file parameter defines the included file as relative to the document path; the virtual parameter defines the included file as relative to the document root.

<!--#include virtual="header.html"-->

exec
cgi or cmd
This directive executes a program, script, or shell command on the server. the cmd parameter specifies a server-side command; the cgi parameter specifies the path to a CGI script. The PATH_INFO and QUERY_STRING of the current SSI script will be passed to the CGI script. "include virtual" should be used instead of "exec cgi".

<!--#exec cgi="/cgi-bin/foo.cgi"-->

or

<!--#exec cmd="ls -l"-->

echo
var
This directive displays the contents of a specified HTTP environment variable. Variables include HTTP_USER_AGENT, LAST_MODIFIED, and HTTP_ACCEPT.

<!--#echo var="REMOTE_ADDR" -->

config
timefmt, sizefmt, or errmsg
This directive configures the display formats for the date, time, filesize, and error message (returned when an SSI command fails).

<!--#config timefmt="%y %m %d" -->

or

<!--#config sizefmt="bytes" -->

or

<!--#config errmsg="SSI command failed!" -->

flastmod or fsize
file or virtual
These directives display the date when the specified document was last modified, or the specified document's size. The file or virtual parameters specify the document to use. The file parameter defines the document as relative to the document path; the virtual parameter defines the document as relative to the document root.

<!--#flastmod virtual="index.html"-->

or

<!--#fsize file="script.pl"-->

printenv
This directive outputs a list of all variables and their values, including environmental and user-defined variables. It has no attributes.

<!--#printenv -->

3. Practical Usage

Today's date

<!--#echo var="DATE_LOCAL" -->

The echo element just spits out the value of a variable. There are a number of standard variables, which include the whole set of environment variables that are available to CGI programs. Also, you can define your own variables with the set element.
If you don't like the format in which the date gets printed, you can use the config element, with a timefmt attribute, to modify that formatting.

<!--#config timefmt="%A %B %d, %Y" -->
Today is <!--#echo
var="DATE_LOCAL" -->

Modification date of the file

This document last modified <!--#flastmod file="index.html" -->

This element is also subject to timefmt format configurations.

Including the results of a CGI program
This is one of the more common uses of SSI - to output the results of a CGI program, such as everybody's favorite, a ``hit counter.''

<!--#include virtual="/cgi-bin/counter.pl" -->

Notice: You need to turn on the SSI support on the server side in advance, otherwise you'll get a bunch of blank pages!

Referrence:

• Wikipedia: SSI -- Server Side Include
• Apache -- SSI Tutorial

Learn from the worst.

I guess there is few things as educational and entertaining as critisizing the worst. Yes, we can always learn from the worst, at least avoid being one of them.

Just type in "worst site" in google to search and you'll get a bunch of sites which are dedicated to listing the worst sites of the world. I bet you'll like them. It's fun, too.

Some sites are listed below.

World's worst site -- This is actually a demostration of some worst graphic design effects. Though not very comprehensive, it's worthwhile to pay a visit.

The worst of the web -- This site is dedicated to listing sites with worst effects yet in a funny, sarcastic tone. Read the comment of the editors. You'll know clearly where is the worst part of the site.

Mystery meat -- This is not a site -- just a part of the site. But it describes an important yet often neglected issue in website usibility, which is called "mystery meat". The terminology is funny, is it? Read the page, then you'll know it's not, at least for site users.

1. Invincible Header Picture

Do you want your header picture span up filling the entire top space when the webpage was viewed in a 1680*1050 resolution monitor, and generate no scroll bar as we resize it into a mobile phone monitor size? If yes, note the following 2 methods.

1) Long long header picture

We can simply generate a long, long picture, as long as you wish. Then put it in the header space of your webpage. You can see, it easily fills up the whole length. But wait, down the windows there is something you'll never want to see: horizontal scrollbar. How to eliminate it?

After hours searching, I discovered the trick: please the header picture in a division, then put script style="width=100%; overflow:hidden". Then you'll find the horizontal scrollbar has disappeared!

See here for example.

2)Background picture
Add an division on the header, then set the background-image the image you want to place. Remember, background image always repeats if you don't set the attribute. If it's a big image which should be shown only once, set the background-repeat:no-repeat. If your only want your picture to repeat vertically or horizontally, set the background-repeat repeat-y or repeat-x.

See here for example.

2. A footer is a footer, is a footer, is a footer......

I guess many designers are complaining about the footers -- the division that should always stay at the bottom. However, thousands of people are trying to achieve this by adding the attribute "bottom:0px" to the footer, which turns out to be never working. But we can never assign the footer with a "top" attribute, since we never know how long our content will be. Then what to do?

The solution is to layout the major divisions in the way of "flow" as we've discussed in the last tutorial. Take a 3-column layout with a header and a footer for example, we place the header at top, style="width:100%; clear:both". Then we assign the medium level "float" attribue. Remember, do not assign any length for the middle column if you want it to be scalable. The last thing, assign "clear:both" to the footer.

See here for the solution.

Supplement to the Fifth tutorial

Here is the missing image which illustrates the uage of float and clear:

Images in the fifth tutorial is created all by myself. Letters are literally typed. Please value my hard working. Thanx.

Fifth Tutorial -- Layout with CSS

Here we meet again. But I guess no body seems to be paying attention to my newsletter, even if I devote 2 hours to typing each letter. And I know that many people seems so unwilling to read through my tutorial that they even complain in their assessments. Well, I do want to make this newsletter a serial tutorial. It's for your good. If you feel boring, you may tell me and we may discuss some changes in presentation. But if you are not satisfied with the content or you just want me to present those materials already shown in the class, I guess this site is not your site to visit.

Talking about layout, we generally will think of 2 modals. I would like to call the first mdal: Pin modal, because in this modal we assign a certain number for the positioning of an object. Say we want image 1 goes up to the top-left side of the webpage, or we want the navigation bar stay always 20px to the right border of the webpage, etc. In CSS, we have a set of attributes to finish positioning, that is top, right, bottom, right and position. The attributes named "top", "right", etc, is easy to understand. They give the direct position information to the browser, helping it to place objects on the screen. The position attribute includes many options, the most commonly used two are illustrated below.

The second model is mostly used in print materials like news paper and books. I would like to call it: flow. Text in the content is like a stream. It flows from up to down, from left to right (though you may change its direction in CSS). When it comes to some blocks, say a piece of image or an input box, it would choose to flow by its left or right side. Or it can even choose to skip the block and appear after the block afterwards. Actually we have been using this modal for long in Microsoft Word and some other word processor. In CSS, the two attributes we use is float, and clear.

I am sorry that I can not up load the other illustration in this entry. So you will see it in another entry. Generally speaking, the two ways interfere with the other. In design, we can only choose one to go--place it somewhere definitely, or let it float as the window resized. And in the flow method, we may only adopt one attribute: float or clear. We can't use both at the same time.

The advantages of using the Pin method are that firstly, it is easy to be done. Calculate carefully then your creationg will be pixel-exact. Secondly, objects can overlap each other to create a feeling of layer. You may use the z-index attribute to decide which stay at top or bottom. But it also shows weakness when we resize the window. Some items we originally don't want to make overlapped now is because resize. Worse still, it's impossible to place a constant footer at the bottom by using this method.

Though not transparently easy to use, the flow method shows great advantage in placing objects among text. If you want your picture surranded beautifully by text flow, this is your choice. It also gives uncomparable flexibility when the web page is resized. The 3-columns page can still look 3-columns after resize. In addition, it enables you to place an constant footer below your page.

Fourth Tutorial -- Why XHTML?

Hi guys.Now begins our fourth tutorial of web standard. I guess you've seen through our previous newsletters, right? Yes, I'm glad you still remember. We've discussed about how we did in HTML in the early days, the deficiency of HTML and the birth of XML. Perhaps some of you might have already come up with a question: Since XML appears so great, why we still need to step into XHTML as an intermediate before getting to XML? Why don't we learn XML directly? That's the issue we are going to discuss.

So firstly, I would like to let you guess: how long did it take for me to learn XML? 1 or 2 years? No. It would take me at least 4 years to learn. The reason I use the word "would" here is that until now I can't say I know XML. I got touch with the idea in senior middle school, 17 years old. I tried to study its manual, but I cound't found any so called manual. Then I turned to some online forums, trying to find some hints about XML. However, I could barely understand a word. "I must be stupid", I thought. Later, I started to realize that I've adopted the wrong way at the first place. I treated XML as a new kind of markup language, and studied it as I studied HTML. Actually, rather than being a concrete language like HTML, XML is more likely to be described as a "standard". It has no tag pre-defined! You are entitled to use anything you want to use, and at the same time you have to define whatever you want to use. Knowing how to define a tag is definitely too much for any novice page builder, which makes XML extremely difficult to learn.

On the other hand, we can't throw away our current web which has been built with HTML for long. It's too huge, and many people are reluctant, too busy or unable to change. Moreover, many people still building websites in HTML. They are too accustomed to the old standard. Browsers also don't want to give up the existing market. Say all the browsers suddenly give up to support unstandard web pages one day, probably, most of the site will crash within several days. HTML, as a long used tool to build the web, still have its reason to exist.

In order to get rid of the deficiency of HTML while still keeping its convenience, scientist devices a "new" language too meet both sides, that is, XHTML. Generally speaking, XHTML is the HTML based on XML. Its page is actually written in XML, with all tags defined in HTML language. That's the trick. When we program in XHTML, we are getting accustomed to XML's standard, conventions, yet still keeping our pages easy to program and available to most of the browsers. To conclude, we may try jumping directly into the jam of XML, or we can choose to taste it bit by bit by learning XHTML.

Referrence: XHTML -- Example by Example

CityU Web Hacker - Butterfly

eXtreme Web Designer Launched!

With great honor I am telling that our site for eXtreme Web Designer contest has hosted here. Please take a visit if you like.