HTML or XHTML

[Uncle Pirate]

I have recently been appointed webmaster of a website
(http://alamo.nmsu.edu). I have done much work on the site as part of
what has been the webmaster committee. The site is old and the design
is old and we are planning a complete revamping of the site. I hope
that only the design will be done by committee and that I will be the
*one* coding the site.

As the webmaster, I will have some say in how things will be done, at
least in the recommendation stage. I am unsure of whether to redo the
site using HTML 4.01 or XHTML 1.1. I want the site to comply with *a*
current standard and of course accessibility.

I would like to see some discussion of the pros and cons between HTML
and XHTML to aid me in my decision as to which I will recommend. I"ve
read enough to know about IE not supporting XHTML. I would like to know
how much of a problem that is as like it or not, it is THE browser out
there and our pages must be usable by it.

--
Stan McCann "Uncle Pirate"
Webmaster/Computer Center Manager, NMSU at Alamogordo
Cooordinator, Tularosa Basin Chapter, ABATE of NM AMA#758681
'94 1500 Vulcan (now wrecked) http://surecann.com/Dcp_2068c.jpg
A zest for living must include a willingness to die. - R.A. Heinlein

 

[Neal]

I have recently been appointed webmaster of a website
(http://alamo.nmsu.edu). I have done much work on the site as part of
what has been the webmaster committee. The site is old and the design
is old and we are planning a complete revamping of the site. I hope
that only the design will be done by committee and that I will be the
*one* coding the site.

As the webmaster, I will have some say in how things will be done, at
least in the recommendation stage. I am unsure of whether to redo the
site using HTML 4.01 or XHTML 1.1. I want the site to comply with *a*
current standard and of course accessibility.

I would like to see some discussion of the pros and cons between HTML
and XHTML to aid me in my decision as to which I will recommend. I"ve
read enough to know about IE not supporting XHTML. I would like to know
how much of a problem that is as like it or not, it is THE browser out
there and our pages must be usable by it.

If you serve XHTML as application/xml+xhtml, then IE cannot use it. There
are ways to sniff out IE and serve it text/html (using server-side
scripting like PHP) just for them, but for the average web author it's a
little involved.

If you are using XML tools to prepare or generate your pages, XHTML might
be worth it even if you don't plan to serve it as application/xml+xhtml
but as plain old text/html.

In environments where you don't plan to use PHP and no XML tools are used
in making the site, there's simply no benefit to using XHTML. HTML 4.01
Strict is the best in that situation, with CSS for layout and
presentation. But you'd do well to become accustomed to employing a few of
the strictures of XML in your HTML, like closing all elements (except
empty ones), using lowercase tags, and being sure your code is valid to
the DTD. In the even you want to move to XHTML, converting such an HTML
page to valid XHTML is a trivial exercise.

 

[SpaceGirl]

If you serve XHTML as application/xml+xhtml, then IE cannot use it. There
are ways to sniff out IE and serve it text/html (using server-side
scripting like PHP) just for them, but for the average web author it's a
little involved.

If you are using XML tools to prepare or generate your pages, XHTML might
be worth it even if you don't plan to serve it as application/xml+xhtml
but as plain old text/html.

In environments where you don't plan to use PHP and no XML tools are used
in making the site, there's simply no benefit to using XHTML. HTML 4.01
Strict is the best in that situation, with CSS for layout and
presentation. But you'd do well to become accustomed to employing a few of
the strictures of XML in your HTML, like closing all elements (except
empty ones), using lowercase tags, and being sure your code is valid to
the DTD. In the even you want to move to XHTML, converting such an HTML
page to valid XHTML is a trivial exercise.

Not quite true... IE will still render the page, but it sort of does it in a
weird way. If you want a site to be relatively furture proof, then I'd
suggest designing in XHTML, but spend the extra effort in making sure you
apply all of the work arounds to get IE to behave(ish). We've got two web
sites now that are pure XHTML (and some XML) and they render just fine in
IE - with the careful use of IE specific stylesheet. All other modern
browsers handle XHTML just fine without any messing around.

 

[Mark Parnell]

I would like to see some discussion of the pros and cons between HTML
and XHTML to aid me in my decision as to which I will recommend.

I basically agree with Neal - unless you are using XML tools to create
the site, XHTML is an exercise in futility. To get IE to render it at
all, you have to pretend it is HTML anyway, so why not just write HTML
in the first place?

 

[Mark Parnell]

But you'd do well to become accustomed to employing a few of
the strictures of XML in your HTML, like closing all elements (except
empty ones), using lowercase tags,

I agree Neal, but I'd add here quoting all attribute values as well.

and being sure your code is valid to the DTD.

I'm not disputing that this is a Good Thing(TM), but since when does it
have anything to do with whether you are using XML, HTML, or Some Made
Up Markup Language?

 

[Neal]

I agree Neal, but I'd add here quoting all attribute values as well.


I'm not disputing that this is a Good Thing(TM), but since when does it
have anything to do with whether you are using XML, HTML, or Some Made
Up Markup Language?

If it won't validate, it won't parse. So even though an HTML document
"works", converting it to XHTML might result in faulty XML. Validation is
one thing you can do toward preventing that, though it isn't sufficient by
itself.

 

[Andy Dingley]

I am unsure of whether to redo the site using HTML 4.01 or XHTML 1.1.

My vote is for XHTML, although I'm less fussy about 1.1 vs. 1.0.

"Latest" is not always "best". Transitional is certainly a good
thing, because there's just no payback in going to Strict. There is a
diminishing payback in complying with any form of web standard when
the common practice is as poor as the typical level - actually
_complying_ to something is itself a big improvement over typical
work.

Go with XHTML over HTML, because there are increasing benefits to you
as a site admin from using XML-based tools to build and maintain the
site.

The only reason to stick with HTML (4.01 Transitional) is this
"Appendix C" issue. It's a local hot potato, but out in the real world
it just isn't a problem. Sure, IE gets it all wrong - but it _works_,
and it works as well as HTML 4 does. So don't lose sleep.

And while the legacy issues get smaller, the benefits of XML get
bigger.


Look at weblog tools as a way of dealing with entry-level CMS (conent
management) issues. You _will_ have other colleagues asking to put
text content up on the site quickly, be it news or a calendar of
events. Weblogs can be a quick fix for this, and they allow RSS
syndication too.

Consider accessibility, and consider it from the outset.

Consider wireless access, because those funny little phone devices are
getting common. Even if it's just the opening hours and the phone
number, someone out there on the road will appreciate the effort.
Just designing around CSS, and having a reasonable fallback layout if
the CSS fails, is often itself a useful level.

Look at the OAI (Open Archives Initiative) on how to handle
museum-level metadata.

 

[The Doormouse]

To get IE to render it at
all, you have to pretend it is HTML anyway, so why not just write HTML
in the first place?

The differences are pretty minor, so if you follow a few rules your pages
will be upgradeable with minimal editing. It really is not all that hard to
make a page XHTML-friendly.

The Doormouse

 

[Nicolai P. Zwar]

I basically agree with Neal - unless you are using XML tools to create
the site, XHTML is an exercise in futility. To get IE to render it at
all, you have to pretend it is HTML anyway, so why not just write HTML
in the first place?

XHTML is less typing.

 

[Mark Parnell]

XHTML is less typing.

How do you figure that? It has 5 characters instead of 4. :-D

Seriously though, XHTML is generally going to be more typing than HTML,
because you have to close all elements. That means that on any empty
elements, you have an extra 2 characters, " /".

The difference will be more if you normally omit optional end tags and
don't quote attribute values in HTML.

 

[David Christopher Weichert]

As the webmaster, I will have some say in how things will be done, at
least in the recommendation stage. I am unsure of whether to redo the
site using HTML 4.01 or XHTML 1.1. I want the site to comply with *a*
current standard and of course accessibility.

You face two problems:

1) Having to serve pages to all sorts of browsers and avoid pages breaking
(or just looking ugly) in them. Also you should care for accessibility, as
you rightly anticipated.

2) Having to write the pages, either yourself or using content contributed
by others. Probably reusing the content later.

For 1) I would stick to HTML 4.01 and the best practices frequently
advertised in this group (avoiding frames, setting alt attributes for your
images, ...). Older Browsers often just don't render XHTML as well, and
while I see fewer users of say Netscape 4.x there is not a month in which
it does not show up in significant numbers in our webserver's logs.

The answer to 2) depends very much on who you work with, what software
you/they use and what they are willing to learn. Perl, vi and the whole
set of Unix tools might suit me well, my co-workers won't touch them. So
instead *we* currently use StarOffice7 (same can be done with the free
OpenOffice). It uses XML internally, which is great because XSLT will
reliably and automagically create HTML 4.01, XHTML 1.1, WML or whatever
you want. You can even write custom XSLT stylesheets for Star/OpenOffice
and it will export HTML preformatted the way you want (say with a link
to index.html on every page) with no need for external XSLT processors.


kind regards
David

 

[Nicolai P. Zwar]

How do you figure that? It has 5 characters instead of 4. :-D

Seriously though, XHTML is generally going to be more typing than HTML,
because you have to close all elements. That means that on any empty
elements, you have an extra 2 characters, " /".

I misfired and shot down my own joke; I meant HTML is less typing, not
XHTML, for the very reasons you just mentioned (one less letter; no
required closing of tags).

The difference will be more if you normally omit optional end tags and
don't quote attribute values in HTML.

Yep.

 

[Mark Parnell]

I misfired and shot down my own joke;

Whoops! Oh, well. It happens. LOL.

 

[Uncle Pirate]

Snipped unrelated banter

I would like to thank everyone for the comments and discussion on this
subject. Very good information to assist in making the decision. From
what I read, it looks as if the consensus is to go with HTML 4.01 strict
since I will be hand coding rather than using XML tools.

One thing that came up in this thread and others is coding for future
enhancement. I disagree with doing this as I feel that if it's worth
doing, just do it from scratch; make it new. In other words, if the
need arose to upgrade one of my sites from one standard to another, the
need would/should also include a redesign.

--
Stan McCann "Uncle Pirate"
Webmaster/Computer Center Manager, NMSU at Alamogordo
Cooordinator, Tularosa Basin Chapter, ABATE of NM AMA#758681
'94 1500 Vulcan (now wrecked) http://surecann.com/Dcp_2068c.jpg
A zest for living must include a willingness to die. - R.A. Heinlein

 

[Neal]

Snipped unrelated banter

I would like to thank everyone for the comments and discussion on this
subject. Very good information to assist in making the decision. From
what I read, it looks as if the consensus is to go with HTML 4.01 strict
since I will be hand coding rather than using XML tools.

One thing that came up in this thread and others is coding for future
enhancement. I disagree with doing this as I feel that if it's worth
doing, just do it from scratch; make it new. In other words, if the
need arose to upgrade one of my sites from one standard to another, the
need would/should also include a redesign.

Well, the beauty of semantic HTML and CSS is that a new design can be
created without making much change at all to the HTML. Like in the CSS Zen
Garden. Why work harder?

 

[m]

One thing that came up in this thread and
others is coding for future
enhancement. I disagree with doing this as I
feel that if it's worth
doing, just do it from scratch; make it new.
In other words, if the need arose to upgrade
one of my sites from one standard to another,
the need would/should also include a redesign.

This is laudible ambition (and you may consider
yourself properly lauded);-) but it is
completely impractical in the software world.

The way software works is that you combine and
reconfigure things that have already been
written, adding some of your own stuff.
Reusable software is not a new idea. First
libraries, then objects were instituted for
this very reason. Much of the w3C's work in
markup is along similar lines of easy reuse.

The closest I ever came to writing things from
scratch was device drivers -- but then someone
else had written the assembler and C compiler I
was using, and the operating system that it ran
out of. It's not like I was throwing switches
on the Eniac.

 

[Michael Bauser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As the webmaster, I will have some say in how things will be done, at
least in the recommendation stage. I am unsure of whether to redo the
site using HTML 4.01 or XHTML 1.1. I want the site to comply with *a*
current standard and of course accessibility.

Like Neal said, unless you *need* XHTML, go with HTML for now.

If you stick to reasonably well-written HTML, it will easy
enough to do a bulk conversion to XHTML when and if you need it.
If you really want to plan for the future, read "Cool URIs don't
change" for some advice on creating assigning URLs that won't
break when you change file formats:

http://www.w3.org/Provider/Style/URI#remove

I've been moving towards the "no file extensions" model on my
websites, and it's working pretty well.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32) - GPGshell v3.01

iD8DBQFA2hVocpuEJT2bpHsRAmnHAJ9H8HKPV3OqxjMDQpgCg2+9cDG39gCdFuWK
q0S4GUZZ+s1+T6olO/lAGAQ=
=0D2J
-----END PGP SIGNATURE-----