XHTML vs HTML

[Michael Laplante]

Okay, I'm a little fuzzy on the differences between XHTML and HTML spec 4
and above. Anyone have a good url / tute they can recommend?

Anyone have thoughts / opinions on the merits / differences / future of. . .
between them?

M

 

[Travis Newbury]

Okay, I'm a little fuzzy on the differences between XHTML and HTML spec 4
and above. Anyone have a good url / tute they can recommend?
Anyone have thoughts / opinions on the merits / differences / future of. . .
between them?

Just because something is new does not make it better.

 

[Benjamin Niemann]

Okay, I'm a little fuzzy on the differences between XHTML and HTML spec 4
and above. Anyone have a good url / tute they can recommend?

Anyone have thoughts / opinions on the merits / differences / future of. .
. between them?

This has been discussed to death in this and other groups. Just google for
the subject.
Note that this discussion is highly controversial, usually triggering
endless threads when raised (let's see what happens this time), and there
is no generally accepted answer, which one is better.

 

[Nikita the Spider]

Okay, I'm a little fuzzy on the differences between XHTML and HTML spec 4
and above. Anyone have a good url / tute they can recommend?

Anyone have thoughts / opinions on the merits / differences / future of. . .
between them?

DOn't be surprised if you're fuzzy, the differences are not as obvious
as you might think.

As Mr. Niemann said, this subject has been discussed at great length
here and elsewhere. Google "XHTML versus HTML" and you'll have your
choice of religious wars to read up on. =)

 

[Toby Inkster]

Okay, I'm a little fuzzy on the differences between XHTML and HTML spec 4
and above.

The only real difference is that XHTML has to obey XML rules, whereas HTML
doesn't. The places it manifests itself are:

1. All elements must be explicitly closed. In HTML some elements have an
optional closing tag (e.g. <p>, <li>) and some elements must never have a
closing tag (e.g. <meta>, <hr>). In XHTML, the closing tags are required.
Optionally, you can compact the opening and closing tags into one tag
(e.g. "<br></br>" crunches down to "<br/>") -- this may improve browser
support.

2. Element and attribute names are case-sensitive. That is, <p> and <P>
are completely different tags -- XHTML uses lower-case for all element and
attribute names, but attribute values still follow HTML rules, as they're
completely consistent with XML syntax.

3. Under HTML there are certain circumstances where attribute values don't
need quoting. Under XHTML, they always need quoting.

There are other minor differences, the full list is here:
http://www.w3.org/TR/xhtml1/#diffs

 

[Michael Laplante]

Okay, I'm a little fuzzy on the differences between XHTML and HTML spec 4
and above. Anyone have a good url / tute they can recommend?

Anyone have thoughts / opinions on the merits / differences / future of. .
. between them?

Oops, didn't realize the controversy surrounding the issue. Disregard this
post -- not interested in starting a debate / flame war / accusations of
trolling, etc

Thx all. . .

M

 

[Michael Laplante]

Michael Laplante wrote:

The only real difference is that XHTML has to obey XML rules, whereas HTML
doesn't. The places it manifests itself are: [etc]

Okay, that seemed easy enough. Why does the issue seem to generate this huge
amount of controversy? I'm using an xhtml template for a project and am now
wondering if there are some major issues I should be aware of.

M

 

[Benjamin Niemann]

Michael Laplante wrote:

The only real difference is that XHTML has to obey XML rules, whereas
HTML doesn't. The places it manifests itself are: [etc]

Okay, that seemed easy enough. Why does the issue seem to generate this
huge amount of controversy?

Many people like debating which one is better. This is just another
incarnation of flamewars like "Windows vs. Linux", "Perl vs. XY", "Amiga
vs. Atari" and so on.

A specificly controversial topic is Appendix C of the XHTML1.0 specification
(serving XHTML1.0 as text/html), which exploits a bug in (almost) all
existing user-agent implementations (the '/>' in empty elements, which
according to SGML rules, which should be applied to text/html documents,
has a different meaning, but is treated as '>' by tag-soup parsers).

I'm using an xhtml template for a project and
am now wondering if there are some major issues I should be aware of.

XHTML has the advantage that you can use lots of generic XML tools to do
your processing on the server-side, e.g. XSLT.
If you are sending the rendered document to the user-agent, you have either
to transform it to HTML or to Appendix C compliant XHTML (or send a 'Please
upgrade your browser' to all IE users).
A generic XML renderer that does not know the special rules of XHTML will
either render all empty elements as "<foobar/>" or "<foobar></foobar>"
(which are equivalent according to XML rules). But empty elements like IMG,
META, BR, .. need the first form (with an additional space before
the '/>'), whereas SCRIPTs pointing to external script files needs the
seconds form.

I'm using lots of XML (XHTML being just a part of it) on the server-side. As
the final step in the processor-pipe there is a 'XHTML to HTML' module. As
explained above you need such a module anyway and a 'XHTML to HTML'
transformation is not really more difficult than a 'XHTML/xml to
XHTML/app.c.' transformation. And for the record: I'm on the 'stick with
HTML4' side

 

[Nikita the Spider]

Michael Laplante wrote:

The only real difference is that XHTML has to obey XML rules, whereas HTML
doesn't. The places it manifests itself are: [etc]

Okay, that seemed easy enough. Why does the issue seem to generate this huge
amount of controversy? I'm using an xhtml template for a project and am now
wondering if there are some major issues I should be aware of.

Inkster's right, there aren't huge differences between HTML and XHTML.
In fact, XHTML 1.0's deliberate goal was just a reformulation of HTML
4.01 as XML. However, in the real world one still has to deliver that
XHTML to the client, and therein lies the rub. Documents delivered via
HTTP come with a content type, and that content-type can say that the
document in question is either HTML or XHTML (or a few other things, but
we'll ignore them for the purposes of this discussion).

OK, so far, so good. The problem is that the 10,000 pound gorilla that
is IE6 barfs when it sees an XHTML content type. So as long as IE6 is a
significant player on the browser scene (which will probably be until
about, oh, 2012), Web developers who want to deliver XHTML via HTTP have
three choices:
1) Ignore IE users
2) Use content-negotiation to deliver HTML to IE and XHTML to everything
else.
3) Deliver XHTML as HTML, which amounts to lying about the content type.

#1 is popularity suicide and #2 is more work than most of us are willing
to do, so most opt for #3. Ian Hickson wrote an oft-cited article
discouraging this practice. It is entitled "Sending XHTML as text/html
Considered Harmful":
http://hixie.ch/advocacy/xhtml

Furthermore, Steven Pemberton, chair of the W3C HTML Working Group said
in 2000, "Therefore, documents served as text/html should be treated as
HTML and not as XHTML. There should be no sniffing of text/html
documents to see if they are really XHTML."
http://lists.w3.org/Archives/Public/www-html/2000Sep/0024.html

In other words, the practice might be common, but there's some
well-informed folks that are against it. The discussion as to whether or
not this is really OK is another religious debate that usually riles
people up into a good froth.

Personally, I prefer XHTML for all of its crunchy XML goodness, but I
also prefer to send my code with the correct content type, so all of my
code is HTML 4.01 Strict. Now if you'll excuse me, there some folks at
the door. Hmmmm, I wonder why they've got tar and feathers...?

 

[Toby Inkster]

Okay, that seemed easy enough. Why does the issue seem to generate this huge
amount of controversy?

Not because of any problem with XHTML itself, but rather because of things
that surround it:-

* the world's most used browser supports XHTML only partially,
and mainly co-incidentally (i.e. because it's close enough to
HTML);

* a lot of XHTML authors don't really know what they're doing
and just treat it like it's "HTML 5";

* the whole "text/html" versus "application/xhtml+xml" issue;

and so on.

 

[Toby Inkster]

Web developers who want to deliver XHTML via HTTP have three choices:
1) Ignore IE users
2) Use content-negotiation to deliver HTML to IE and XHTML to everything else.
3) Deliver XHTML as HTML, which amounts to lying about the content type.

4) Deliver XHTML as "application/xml" to IE with a "pass-through" XSLT
transformation. see: http://www.w3.org/MarkUp/2004/xhtml-faq#ie

 

[Travis Newbury]

Oops, didn't realize the controversy surrounding the issue. Disregard this
post -- not interested in starting a debate / flame war / accusations of
trolling, etc

Whimp. You have no place in usenet....

 

[Els]

Whimp.

<g>

 

[Nikita the Spider]

4) Deliver XHTML as "application/xml" to IE with a "pass-through" XSLT
transformation. see: http://www.w3.org/MarkUp/2004/xhtml-faq#ie

Never heard of that one before, thanks. Is it used much in practice?

 

[Toby Inkster]

Never heard of that one before, thanks. Is it used much in practice?

Not really. Seems to work fairly well though. Probably best used in
conjunction with content negotiation to serve as "application/xhtml+xml"
for those browsers that can handle it. It has an advantage over serving as
"text/html" for IE though: it forces IE to use its XML parser before
handing it over to the HTML rendering engine. You may end up in quirks
mode though.