difference - What is the difference betwenn HTML and XhTML....?

zeeshan_2011 · 18th February 2010, 06:33 AM

What is the difference betwenn HTML and XhTML....?

MinatureCookie · 18th February 2010, 11:28 AM

HTML is HyperText Markup Language, and XHTML is eXtensible HyperText Markup Language.
In layman's terms, XHTML is nicer for the browser to understand. It's a stricter version of HTML. I imagine it like HTML is slang, and XHTML is proper-English. Although I'm sure that's a very loose analogy. :P

XHTML vs HTML
W3Schools have a very nice article on it.

saltedm8 · 18th February 2010, 11:54 AM

on top of what has already been said, the xhtml doctype also covers xml ( as a separate language entity ).

XML is not a replacement for HTML.
XML and HTML were designed with different goals:

XML was designed to transport and store data, with focus on what data is.
HTML was designed to display data, with focus on how data looks.

it should be said that internet explorer does not support xml, so as a result when you render a xhtml based site on it, really its producing html.

xhtml is not in any way 'cleaner' to code with, its rules are stricter and in my personal opinion better for that reason but in reality ( from a usage point of view ) it does not do anything more than to offer the ability to use xml scripting in your websites.

asdfghjkl9 · 26th February 2010, 03:30 AM

Short for Extensible Hypertext Markup Language, a hybrid between HTML and XML specifically designed for Net device displays.
XHTML is a markup language written in XML; therefore, it is an XML application.

XHTML uses three XML namespaces (used to qualify element and attributes names by associating them with namespaces identified by URI references. Namespaces prevent identically custom-named tags that may be used in different XML documents from being read the same way), which correspond to three HTML 4.0 DTDs: Strict, Transitional, and Frameset.

XHTML markup must conform to the markup standards defined in a HTML DTD.

When applied to Net devices, XHTML must go through a modularization process. This enables XHTML pages to be read by many different platforms.

A device designer, using standard building blocks, will specify which elements are supported. Content creators will then target these building blocks--or modules.

Because these modules conform to certain standards, XHTML's extensibility ensures that layout and presentation stay true-to-form over any platform.

Jack_smith · 5th May 2010, 01:15 PM

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

In HTML, some elements can be improperly nested within each other, like this:

This text is bold and italic

In XHTML, all elements must be properly nested within each other, like this:

This text is bold and italic

stu2000 · 5th May 2010, 02:20 PM

Just to confuse things... This post reminded me of another post over in the 'Just Starting Out' section:

Quote:

Originally Posted by Mike Hopley

Ironically, some of these so-called "best practices" (always close your tags; always quote attributes) are being turned on their heads. In their article on optimising HTML, Google recommend leaving this stuff out, as doing so decreases the size of your web page! I'm not entirely sold on their arguments, but it's good to get a different perspective.

I agree with Mikes original post, not entirely sold on this idea and this does say to 'optimise html', and not xhtml. And most people should be standardising to xhtml now anyway, no?

My my 2 cents!

Mike Hopley · 5th May 2010, 07:02 PM

The "XHTML vs. HTML" issue almost always causes confusion. In practice, there is very little difference between the two.

The browser doesn't pay much attention to your doctype. The only reason you need a doctype is to make sure the browser uses "standards mode" for rendering. If you leave out the doctype, browsers switch to a legacy rendering mode called "quirks mode".

Oh, there is one more purpose for a doctype: validators use it to decide which rule-set to validate against. For example, switching to a <!doctype html> will cause some validators to think your code is invalid, but it makes absolutely no difference to the browser (browsers do not validate your code).

Using an XHTML doctype does not mean you are using XHTML. Browsers read the MIME type instead. If you want your page to work with IE, you will be using a text/html MIME type; for example:

Code:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

(Or you could configure your server to send this information in the document header.)

The browser will then parse your XHTML code as HTML -- and slightly mangled HTML, in fact. In practice, however, the mangling doesn't seem to matter: browsers are good at second-guessing your markup mistakes.

So there you have it. You can use fake XHTML, and validate against a slightly different set of syntax rules; or you can use real HTML. Either way, it makes little difference.

Quote:

And most people should be standardising to xhtml now anyway, no?

Why?

HTML does everything that (fake) XHTML does, and I can serve it with a correct MIME type so that the browser receives valid (non-mangled) code.

Quote:

In layman's terms, XHTML is nicer for the browser to understand.

That statement is absolutely false -- at least if applied to fake XHTML. And even if you were talking about real XHTML (which almost no one uses), I strongly doubt it makes any real difference (either positive or negative).

Quote:

not entirely sold on this idea and this does say to 'optimise html', and not xhtml.

Well, it wouldn't make any real difference to the XHTML you guys are all using, because that's fake.

Sure, the validator would kick up a fuss, but the browser wouldn't care (remember: the browser thinks you're feeding it HTML).

Nevertheless, I recommend avoiding this optimisation -- or at least, be careful what you leave out. It turns out that omitting tags like <html>, <head>, and <body> can, in certain circumstances, wreck the DOM in IE!

I'm astonished that Google is advocating such a dangerous practice.

Mike Hopley · 6th May 2010, 09:07 AM

Just thinking about the speed issue:

What would happen if you served (real) XHTML to a browser, and flushed the buffer early? You would then be delivering the XHTML document in two fragments.

With HTML (or fake XHTML, which is the same), browsers can handle this: they can render the first document fragment even before the rest of it arrives. This works because the DOM is implied in HTML. For example, the browser does not need to see a closing </html> tag in order to create the corresponding DOM element (and you can indeed leave out the </html> tag).

In XHTML this isn't true. XHTML documents must be well-formed, or the browser will (should!) throw an error (i.e. the page breaks completely).

Flushing the buffer early allows for enhanced progressive rendering. It's mainly useful when a heavy database query gets in the way of delivering the HTML.

It seems to me that this enhanced progressive rendering would not work in XHTML. The well-formedness requirement of XHTML, and lack of an implied DOM, should mean that the browser must wait until it has received the full XHTML document before it can start rendering.

Thoughts?

18th February 2010, 06:33 AM	#1
zeeshan_2011 Whacked Join Date: Feb 2010 Posts: 13 Thanks: 0 Thanked 0 Times in 0 Posts Expertise: Total Beginner Experience: Basic / None	difference What is the difference betwenn HTML and XhTML....?

18th February 2010, 11:28 AM	#2
MinatureCookie Member Join Date: Jan 2009 Location: Hampshire, UK Posts: 226 Thanks: 3 Thanked 6 Times in 6 Posts Expertise: (X)HTML / CSS Experience: Professional	HTML is HyperText Markup Language, and XHTML is eXtensible HyperText Markup Language. In layman's terms, XHTML is nicer for the browser to understand. It's a stricter version of HTML. I imagine it like HTML is slang, and XHTML is proper-English. Although I'm sure that's a very loose analogy. :P XHTML vs HTML W3Schools have a very nice article on it. __________________ MinatureCookie.com

18th February 2010, 11:54 AM	#3
saltedm8 Join Date: Dec 2008 Location: Kent Uk Posts: 1,595 Blog Entries: 6 Thanks: 15 Thanked 49 Times in 49 Posts Expertise: (X)HTML / CSS Experience: Professional	on top of what has already been said, the xhtml doctype also covers xml ( as a separate language entity ). XML is not a replacement for HTML. XML and HTML were designed with different goals: XML was designed to transport and store data, with focus on what data is. HTML was designed to display data, with focus on how data looks. it should be said that internet explorer does not support xml, so as a result when you render a xhtml based site on it, really its producing html. xhtml is not in any way 'cleaner' to code with, its rules are stricter and in my personal opinion better for that reason but in reality ( from a usage point of view ) it does not do anything more than to offer the ability to use xml scripting in your websites. __________________ web design kent

5th May 2010, 01:15 PM	#5
Jack_smith Junior Member Join Date: May 2010 Posts: 3 Thanks: 0 Thanked 0 Times in 0 Posts Expertise: Total Beginner Experience: Basic / None	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 In HTML, some elements can be improperly nested within each other, like this: <b><i>This text is bold and italic</b></i> In XHTML, all elements must be properly nested within each other, like this: <b><i>This text is bold and italic</i></b>

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

26th February 2010, 03:30 AM	#4
asdfghjkl9 Junior Member Join Date: Feb 2010 Posts: 13 Thanks: 0 Thanked 0 Times in 0 Posts Expertise: Html Experience: Quite Good	Short for Extensible Hypertext Markup Language, a hybrid between HTML and XML specifically designed for Net device displays. XHTML is a markup language written in XML; therefore, it is an XML application. XHTML uses three XML namespaces (used to qualify element and attributes names by associating them with namespaces identified by URI references. Namespaces prevent identically custom-named tags that may be used in different XML documents from being read the same way), which correspond to three HTML 4.0 DTDs: Strict, Transitional, and Frameset. XHTML markup must conform to the markup standards defined in a HTML DTD. When applied to Net devices, XHTML must go through a modularization process. This enables XHTML pages to be read by many different platforms. A device designer, using standard building blocks, will specify which elements are supported. Content creators will then target these building blocks--or modules. Because these modules conform to certain standards, XHTML's extensibility ensures that layout and presentation stay true-to-form over any platform.

6th May 2010, 09:07 AM	#8
Mike Hopley Member Join Date: Jul 2009 Posts: 191 Thanks: 0 Thanked 18 Times in 17 Posts Expertise: (X)HTML / CSS Experience: Quite Good	Just thinking about the speed issue: What would happen if you served (real) XHTML to a browser, and flushed the buffer early? You would then be delivering the XHTML document in two fragments. With HTML (or fake XHTML, which is the same), browsers can handle this: they can render the first document fragment even before the rest of it arrives. This works because the DOM is implied in HTML. For example, the browser does not need to see a closing </html> tag in order to create the corresponding DOM element (and you can indeed leave out the </html> tag). In XHTML this isn't true. XHTML documents must be well-formed, or the browser will (should!) throw an error (i.e. the page breaks completely). Flushing the buffer early allows for enhanced progressive rendering. It's mainly useful when a heavy database query gets in the way of delivering the HTML. It seems to me that this enhanced progressive rendering would not work in XHTML. The well-formedness requirement of XHTML, and lack of an implied DOM, should mean that the browser must wait until it has received the full XHTML document before it can start rendering. Thoughts?