In an interview I was asked a question that I'd never thought about, which was "We already have HTML which fulfills all the requirements of writing a web page, so what's the need for XHTML?"
I Googled a lot and also read many articles, but I'm not able to get properly why XHTML has been introduced. Please explain to me.
Because it is valid XML. That helps a lot since you can use a lot of tools originally designed for XML, such as XML parsers, XSLT, XPath, XQuery, ...
Normal HTML is a SGML dialect and that is not parsable without knowledge of the schema.
<ul>
<li>one
<li>two
<li>three
</ul>
is correct HTML but not correct XML. If you want to parse that, you have to know that ul-elements have to be closed but li s don't.
I am sure you mustve encountered this article from W3.There is a lot to learn from that article. In short XHTML abides the xml rules besides having HTML set of tags. The Most Important Differences:
* XHTML elements must be properly nested
* XHTML elements must always be closed
* XHTML elements must be in lowercase
* XHTML documents must have one root element
I think that it helps browsers correctly display the html without making assumptions about where tags should be closed. Any time a browsers assumes something you know what happens.
In addition to Johannes answer, HTML is far too loose in its interpretations and tolerance, where XHTML's strict formalisation negates this.
Tolerance leads to variance, which leads to browser incompatibilities, which leads to the dark side.
XHTML is an attempt to encourage the development of "well-formed" HTML.
HTML has evolved over more than 10 years. Its implementation, and the implementation of the browsers that parse and render it, are not exactly consistent. This is why cross-browser compatibility is a major headache.
HTML is based on SGML (Standard Generalized Markup Language.) XML is also derived from SGML, so they are cousins of a sort. XHTML marries the two, providing (in theory) the benefits of XML to HTML. This includes a well-defined schema that can be reliably validated, queried, and transformed.
XHTML also allows you to embed other XML dialects like MathML, Ruby, SVG, etc. (You can also embed XHTML in other XML dialects, if desired.)
If you are just 'making a web page', you don't necessarily need XHTML. But if you are programmatically generating a page, you might find that the tools for generating XML are better than those that generate HTML.
From Wiki:
Because they need to be well-formed, true XHTML documents allow for automated processing to be performed using standard XML tools—unlike HTML, which requires a relatively complex, lenient, and generally custom parser. XHTML can be thought of as the intersection of HTML and XML in many respects, since it is a reformulation of HTML in XML.
Having HTML conform to XML standards allows for a much more consistent parsing of the page. Whereas in HTML, for example, you were allowed to have tags out of order <b><u>test</b></u> now you can't, they must be closed in the order they were opened. Things like this make DOM parsing (which is now used heavily in AJAX) much easier.
I am actually writing this to ask why the above three posts which speak about browser-consistence and well formed html have been voted down?
As it is known HTML is a industry standard. Browsers are implemented so that they render the marked up content as described in the HTML standard. Unfortunately there are areas that have not been well defined in HTML: what happens if user forgot a closing tag or what to do if a referred image is not found? some browsers use the 'alt' tag to have a place holder text item and some browsers display the 'alt' tag as a tool tip. The famous 'quirks' mode of browsers is a result of this lack of clarity. Because of this, it became quite possible that the same web page would display differently on different browsers.
Also as HTML usage grew there was one more problem: it was not extensible - there was no way to add user-defined tags.
XHTML solves the above problems:
XHTML has well defined rules about the structure and these can be programatically enforced. Check the various online "XHTML Validators". They will tell if your XHTML is well formed or not (and highlight the problem areas). Because of these strict rules your page is more or less guaranteed to look the same on all browsers implementing XHTML.
[note] if you want to verify the above, please refer to the text "Head First XHTML and CSS"
XHTML forces you to write cleaner code which is easier to maintain, renders more consistently, and easier to hook into the DOM. Comparing XHTML to HTML is like comparing a programming language that is strongly-typed to a programming language that is loosely-typed.
As mentioned above, XHTML allows you to play with SVG and MathML. I'd like to add RDFa to that list. RDFa allows you to add semantics to your content that is not covered by microformats. I've personally been doing a lot with Dublin Core and Friend-of-a-Friend.
XHTML is simply about communication between systems. HTML is very difficult to parse, because of the number of variations that can occur as to what is well formed. Since XML is strict in its interpretation, this problem has been removed.
Think about a RESTful architecture. If a URL is permanent location to an item, then systems which would want to access this item should be able to consume the information returned from accessing the URL. XHTML doesn't make this possible per se, because a system could already parse the HTML and retrieve the necessary information. XML just makes this easier. There is no limiting predefined set of tags which make it difficult to classify data in a document (althought techinically you can do this in HTML, because browsers will ignore it). You can use whatever you want to classify what data is retrieved.
If i want to crawl your site, and parse its contents, i can only do it if it's XML.
Parsing HTML is a nightmare.
XML is a data interchange format - this is perfect for building websites because after all we are dealing with information and this info needs to be crawled and understood by computers (such as search engines).
Because XHTML makes a lot more sense!
The point is, even though something might not provide any more technical possibilities, it's still an improvement if it's remade just to be more clear and logical. That's why code refactoring is a good idea even if it doesn't change any of the functionality. That's why Brainfuck wound't be a good programming language, even if it had all the capabilities of Java.
XHTML makes more sense because the underlying structure of tags and their attributes is always consistent - not dependent on the tag semantics. The way it makes more sense is pretty evident, once you get familiar with its difference to HTML, but for example tags are always orderly nested, all tags must close, names must be lowercase, attribute values must have limiting characters around them.
Why was XHTML created?
How well has it succeeded?
What is the need for XHTML?
XHTML had laudable goals and maybe it will be able to deliver in the future. I can't recommend XHTML for the possible future advantages it might provide, when HTML is much easier now. You should only really use XHTML if previous code or your tools force you to.
In a nut: XHTML is often only beneficial and preferred over HTML whenever you want to use a XML based tool to manipulate/transform/generate HTML pages on the server side.
Lot of examples can be found in component based MVC frameworks like Sun Oracle JSF which uses Facelets as a XHTML based view technology. The server side components are definied in XSD's and the pages are parsed using a SAX parser. You can even add a <!DOCTYPE html> to top of the page to let Facelets generate "pure" valid and strict HTML5. Microsoft ASP.NET MVC has a similar view technology.
When you're hand-writing HTML, XHTML doesn't add much benefit, or it must be pushing off the "coolness" of using a (over)hyped technology.
I see a bunch of up-voted answers here that are making incorrect assumptions about how browsers work. So let me give my 2 cents on the matter.
First of all, why does XHTML exist?
a two-day workshop was organised to discuss whether a new version of HTML in XML was needed. The opinion at the workshop was a clear 'Yes': with an XML-based HTML other XML languages could include bits of XHTML, and XHTML documents could include bits of other markup languages. We could also take advantage of the redesign to clean up some of the more untidy parts of HTML, and add some new needed functionality, like better forms.
In short, XHTML was created for two reasons:
Making things easier to validate was not a design goal, and also not something that was necessary because HTML4 validators exist and are comprehensive.
Is XHTML easier to parse for browsers?
Yes and no. XML is easier to parse than HTML tag soup, but, unless you use an xhtml+xml or application/xml mime type for your XHTML page, browsers parse it using the HTML parsing engine. However, if you do use xml mime types, IE chokes on your content. This behavior is explained on the IE blog. There is no difference in how browsers treat XHTML and HTML if you are serving it with a mime type of text/html!
Yes they do! You lie!
Indeed they do, but only because of the doctype. Browsers use doctypes at the top of HTML documents to determine whether they should use standards mode or quirks mode (= bugs mode). All valid XHTML documents happen to include a doctype that triggers standards mode. However, in HTML you can get the same result by including "<!doctype html>" at the top of your page.
So are you saying XHTML has no purpose?
Not at all. XHTML has many advantages:
So, I should use it then?
As always, the answer is "it depends".
What about HTML5? Does it compete with XHTML?
No it doesn't. HTML5 has two serializations, one as HTML, and one as XML. The benefit is that both now have strict parsing rules. You will get predictable behavior in all browsers regardless of the approach you use. However, HTML5 parsed as HTML has the benefit of graceful error handling. That's why I prefer that approach. As always, YMMV.