You are here: Re: XHTML or HTML 4 ? « HTML « IT news, forums, messages
Re: XHTML or HTML 4 ?

Posted by Gιrard Talbot on 01/19/06 22:08

Marc wrote :
> Marc wrote:


>
> Okay, so I've heard the disadvantages of using HTML

? If you use strict definition of HTML 4.01, I see no disadvantages.

I personally moved from XHTML 1.0 strict to HTML 4.01 strict about a
year ago after reading

Sending XHTML as text/html Considered Harmful
http://www.hixie.ch/advocacy/xhtml

Say NO to XHTML
http://www.spartanicus.utvinternet.ie/no-xhtml.htm

I'm not alone to have done this. David Dorward, a regular poster in web
programming newsgroups, did the same. Also, recently, Benjamin Smedberg
did the same. See

HTML 4.01
http://benjamin.smedbergs.us/blog/2006-01-16/valid-html401/

where he interestingly writes:
"This blog is now valid HTML4.01 strict! By default, WordPress uses
XHTML with a text/html mime type, which I think is an abysmal choice.
And I don't care much for XHTML anyway (HTML4 with WhatWG extensions is
the future of the web), so I hacked my theme a little bit more and wrote
a little Wordpress plugin which disables a few XHTMLiries that WordPress
uses by default; these combined changes make this blog validate as
HTML4.01 strict."

Nvu User Guide recommends to its users to go for HTML 4.01 strict.


and also the
> question "why use XHTML when you don't need to?" posed a lot. What
> about some disadvantages of using XHTML - what reasons are there *not*
> to use it?
>

A lot of people already answered lengthly your double question in this
thread.

Need more reading? How about:

XHTML is dead
http://www.autisticcuckoo.net/archive.php?id=2005/03/14/xhtml-is-dead

> Also, I found this article:
> http://www.yourhtmlsource.com/accessibility/xhtmlexplained.html - which
> I have taken an excerpt from and pasted below. Would anyone care to
> comment?
>
> "The benefits of adopting XHTML now or migrating your existing site to
> the new standards are many. First of all, they ensure excellent
> forward-compatibility for your creations.

A transitional DTD does not have an assured forward-compatibility but a
strict one does. And with the current status of XHTML, I would not say
that, XHTML as defined/specified right now, is a solid guarantee of what
it will be in the future. I'm not an expert at this but it certainly
seem so.

Also, since MSIE 7 will not be supporting application/xhtml+xml, then it
certainly invite web authors to use HTML 4.01 for the next 10 years, at
least.

> XHTML is the new set of
> standards that the web will be built on in the years to come, so
> future-proofing your work early will save you much trouble later on.

That is what was expected but it doesn't seem clear anymore.

> Future browser versions might stop supporting deprecated elements from
> old HTML drafts, and so many old basic-HTML sites may start displaying
> incorrectly and unpredictably.

But this is *_exactly_* what I would say regarding transitional DTD
versus strict DTD.
In strict DTD, elements and attributes used for presentational/style are
formally deprecated, not recommended anymore.

Go and examine the code of that article
http://www.yourhtmlsource.com/accessibility/xhtmlexplained.html
of yours:
target="_top"
bgcolor="#ffffff"
text="#000000"
are formally deprecated attributes but the markup code of that article
uses these anyway.

<h1 align="center"
is use of deprecated align.

etc,etc, etc.. That article is another good example of a webpage that
uses deprecated attributes which are not assured to be rendered in the
future. That is: XHTML markup code with deprecated attributes. The
article itself is in blatant contradiction here.

> Once you have used XHTML for a short time, it is no more difficult to
> use than HTML ever was, and in ways is easier since it is built on a
> more simplified set of standards.

What does prevent a web author from editing HTML elements with closing
tags when using HTML 4.01 strict?

e.g.:
<ul>
<li>blue
<li>red
</ul>

<ul>
<li>blue</li>
<li>red</li>
</ul>

Both lists above are valid HTML 4.01 strict but there is one which will
be parsed faster in all modern (web standards compliant) browsers.

What does prevent a web author from using lowercase for HTML elements
and for HTML attributes in HTML 4.01 strict?
What does prevent a web author from always quoting HTML attributes in
HTML 4.01 strict?
Quoting attribute values is one simple way to speed up parsing and
rendering in all modern browsers.

What does prevent a web author from avoiding attribute minimization when
using HTML 4.01 strict?

What does prevent a web author from using Tidy to eradicate more
unneeded code and small conformance errors that a validator cannot/does
not report, even in XHTML?

Several HTML elements are optional (body, html, tbody, etc.) in HTML
4.01 strict... but there is nothing preventing a web author from
explicitly declaring these.

> Writing code is a more streamlined
> experience, as gone are the days of browser hacks and display tricks.

One can still misuse markup code when writing an XHTML 1.0 page, even a
valid XHTML 1.0 page.
One can still use table for layout in XHTML. One can still use lots of
&nbsp; to create a padding effect in XHTML. One can still use
<blockquote> solely for the purpose to create a text indentation in
XHMTL. One can still use spacer.gif's in XHTML, lots of <br> instead of
CSS margin in XHTML, etc, etc, etc.
In fact, since Macromedia DreamWeaver has been able to use and render
XHTML, this is exactly the kind of markup code which was again and again
created, output, produced anyway and again: browser hacks and display
tricks but this time in XHTML !

"tables do a pretty lousy job of page construction. Among their
shortcomings is the implied bias of the code towards presentation rather
than structure, the necessity to nest tables in order to achieve the
most basic of layouts, and enough redundant bandwidth-hogging tags to
feed a large family of tag eating monsters for literally a month."
Tableless layout with Dreamweaver MX
http://www.macromedia.com/devnet/mx/dreamweaver/articles/tableless_layout.html


WYSIWYG Web tools comparison with hand-coded markup code. Everywhere,
hand code is better
http://www.backupbrain.com/2002_11_17_archive.html#a003122


> Editing your existing code is also a nicer experience as it is
> infinitely cleaner and more self-explanatory.

Cleaner? Not necessarly. This mostly depends on the web author
experience. Self-explanatory? Not true. This again depends entirely on
the web author's experience at wisely choosing semantic, giving
intuitive and self-explanatory identifiers to id attributes, class
attributes and at understanding of semantic markup.

If markup code is not enforced by browsers and by defined error
corrections in the specs, then XHTML is not an advancement over HTML,
especially when browsers are lead to accept XHTML served as tag soup.


Browsers can also
> interpret and display a clean XHTML page quicker than one with errors
> that the browser may have to handle.

But that is also true for strict HTML 4.01. This is not an advantage of
XHTML over HTML 4.01.

>
> A well-written XHTML page is more accessible than an old style HTML
> page,

A well-written strict HTML 4.01 page is/can be as accessible as a
well-written XHTML page. Missing alt attributes are reported as errors
by HTML 4.01 validation. XHTML code does not ensure accessibility of a
page more than an HTML one. A well written HTML webpage can be and will
be more accessible than a poorly written XHTML page.

and is guaranteed to work in any standards-compliant browser
> (which the latest round have finally become) due to the insistence on
> rules and sticking to accepted W3C specifications. As mentioned above,
> XHTML allows greater access to configurations other than a computer and
> browser. This interoperability is another aspect of XHTML's greater
> accessibility."

Even that last sentence is debattable. A valid, compliant and conformant
is a much better promise of interoperability than just usage of XHTML.

GΓ©rard
--
remove blah to email me

 

Navigation:

[Reply to this message]


УдалСнная Ρ€Π°Π±ΠΎΡ‚Π° для программистов  •  Как Π·Π°Ρ€Π°Π±ΠΎΡ‚Π°Ρ‚ΡŒ Π½Π° Google AdSense  •  England, UK  •  ΡΡ‚Π°Ρ‚ΡŒΠΈ Π½Π° английском  •  PHP MySQL CMS Apache Oscommerce  •  Online Business Knowledge Base  •  DVD MP3 AVI MP4 players codecs conversion help
Home  •  Search  •  Site Map  •  Set as Homepage  •  Add to Favourites

Copyright © 2005-2006 Powered by Custom PHP Programming

Π‘Π°ΠΉΡ‚ ΠΈΠ·Π³ΠΎΡ‚ΠΎΠ²Π»Π΅Π½ Π² Π‘Ρ‚ΡƒΠ΄ΠΈΠΈ Π’Π°Π»Π΅Π½Ρ‚ΠΈΠ½Π° ΠŸΠ΅Ρ‚Ρ€ΡƒΡ‡Π΅ΠΊΠ°
ΠΈΠ·Π³ΠΎΡ‚ΠΎΠ²Π»Π΅Π½ΠΈΠ΅ ΠΈ ΠΏΠΎΠ΄Π΄Π΅Ρ€ΠΆΠΊΠ° Π²Π΅Π±-сайтов, Ρ€Π°Π·Ρ€Π°Π±ΠΎΡ‚ΠΊΠ° ΠΏΡ€ΠΎΠ³Ρ€Π°ΠΌΠΌΠ½ΠΎΠ³ΠΎ обСспСчСния, поисковая оптимизация