HTML or XHTML?

[Grant Palin]

I am thinking of doing a(nother) website, and have been wondering about whether to use HTML or XHTML. Is there really any difference between the two? Is one better than the other? I already know HTML, and have no knowledge of XHTML, and it would be great if I didn't have to learn something new to do the webpage. Is is possible to convert HTML to XHTML after it is written, or should I start with XHTML from scratch?

[Nightfire]

TBH I don't know that much about xhtml, but I heard that it's supposed to take over the role of html now or in the future.

[Grant Palin]

So it would be a good idea to move up to the current version?

[umm]

XHTML is an XML application. It's primary aims are
(a) extensibility - it's vocabulary can be more easily added to (manipulated) and,

(b) portability - in theory, it should be able to be shared across a wide variety of user agents. In other words, there can be no proprietary tags.

HTML 4.01 is the last and final version of HTML. XHTML has taken the HTML4.01 markup and used them to make an XML application. For all practical purposes, XHTML is just a stricter version (in terms of syntax) than HTML.

I doubt whether XHTML will replace HTML any time soon. UserAgents have to be backward compatible to some degree or another (imagine a browser that didn't support HTML!)

It's not hard to upgrade from HTML to XHTML. I use XHTML but I really wonder why I should. It offers me no extra functionality (at this stage).

In the end, I think it's just that I like the "X" in front of HTML ;)

[ronaldb66]

If i understand correctly (no, really), no browser will choke on strict and valid XHTML, even if it doesn't support it. A number of rules behind coding strict XHTML should yield better, cleaner code, so i personally would recommend to adhere to at least those rules, like closing all container elements with the appropriate end tag, properly nesting container elements, enclosing all attributes in quotes, etc.
Moreover, if your code is strict, you can apply a validator to check it to make sure you didn't leave any typos.
I would recommend taking the step to XHTML!

[allida77]

XHTML will be great when it becomes more popular because it will force people to write cleaner code (easy debug). For now it is just hype. If you are creating static web sites do not bother with trying to learn XHTML . The only reward now is getting a cool "W3C valid XHTML" icon on the bottom of your site.

[Bosko]

XHTML 1.0 is meant to be backward compitable,so its just HTML with the XML syntax,XHTML 2 on the other hand will be really diferent with alot of new functionality.

Its realy recommended to switch to XHTML,since its makes your site cross-browser.XHTML doesnt contain propriatary ****,and the syntaxt valid,so all browser should render it the same.And it isnt any harder to do,if you have DreamWeaver MX you just have to configure it to use XHTML and youre done.

[jkd]

Originally posted by allida77
The only reward now is getting a cool "W3C valid XHTML" icon on the bottom of your site.

And not having to rewrite it later. :rolleyes:

If I write something in XHTML 1.0 Strict or XHTML 1.1 right now, I can be pretty much assured it will work perfectly in web browsers 5 years down the line. If I leave it in HTML, no guarentees. And not only that, but say an entirely new format takes over for webpages. With HTML, you'd be stuck writing it over by hand (at least until a converter comes out, which probably will not get it exactly). With XHTML, you could write a simple XSLT transformation sheet to convert it to the new format, and apply the sheet to all of your pages. Instant change.

XHTML 1.0 is backwards compatible with HTML4 (<br/> is valid HTML, but NS4 requires <br /> to render it, and that's the only exception), so really the only question is, why not?

[Roy Sinclair]

Originally posted by jkd
... so really the only question is, why not?

The best reason to use xHTML now is so you loose all the bad habits that years of coding for browsers that accept all manner of bad code. Otherwise you can continue coding the way you have in the past and try to break all those habits only when it becomes absolutely necessary, of course you'll get lots of practice as you have to go back and fix all the bad code you generated in the past.

Not trying to shoot anyone in particular here but any time at all spent looking at the code for various sites is an exercise in the amazing ways that bad code can be done while the page still works (or more often, mostly works).

Imagine how much more trim and quick a browser could be if it didn't have to spend a lot of CPU and memory supporting all the defects in the way people use HTML just so the browser doesn't appear to break millions of sites (when the truth is that it's those millions of sites that are broken). A serious mistake in browser development was to make the browser forgive bad html in the interest of being competive against the leading browser which also forgave bad html. All that did was encourage the use of bad html because people would tweack the html until it "looked" right when viewed with the browser.

[Alex Vincent]

:) Be nice if this thread was in my forum, but...

One of the major advantages of XHTML (particularly 1.1 and the upcoming 2.0) is the ability to intermix other XML languages with XHTML. For instance, with XHTML 1.1 + MathML 2.0, a DTD the World Wide Web Consortium provides, you can include MathML equations in an XHTML document without any real validation problems. (Of course, Internet Explorer is psychotic on the W3C's DTD for that sort of document. ;) )

There's also one more very important reason to start writing XHTML. Because it is XML, it forces you to code very correctly, very strictly. That same strictness helps a great deal in stabilizing the Document Object Model for your document.

In other words, serious JavaScripters should consider writing XHTML from the start. :cool:

[ddubs]

The W3C HTML Home Page (http://www.w3.org/) has lots and lots of information on ths subject and more...

here is a list of recomendations on XHTML (http://www.w3.org/MarkUp/#recommendations). There is alot of other useful reading if you are serious about putting the energy into it. (which is really not that much!)

and off the subject...you should also look into XFORMS (http://www.w3.org/MarkUp/Forms/) as well.

good luck!!:thumbsup:

[Grant Palin]

What does XHTML do to javascript? I used the W3C Validator, and it had problems with simple onMouseOver and onMouseOut statements, with images. Any idea what's going on?

[umm]

onMouseOver should be onmouseover. In XHTML tags, element names, attributes etc are written in lowercase. Tags without a closing tag, such as the <img> element need a closing "/" like this:
<img src="blah.gif" />

The same goes with form input elements as it does with <br /> and <hr />

[BrainJar]

If you know how to write valid HTML, then you pretty much know 99% of XHTML, at least XHTML 1.0.

Try http://www.w3schools.com/xhtml/default.asp for a quick overview.

[Grant Palin]

I fixed the onmouseover and onmouseout- no errors from that anymore.

However, I'm still getting an error with the Character Encoding- none detected. What's that about? Here's the link to the validation page.

http://validator.w3.org/check?uri=http://www.freewebs.com/hommworld/

[Grant Palin]

Also, on a framed page, I'm being told there are no frameborder and framespacing attributes in this version of HTML. Is that right? Are there replacements?

[oracleguy]

Are you using the right DTD for your frameset page?

There is a special one for framesets.

I'm all for xHTML. The W3C hopes to eventually make XML the standard and bail on HTML.

Coverting to XHTML from HTML isn't really that hard. And plus, if you start now you it will be much easier for you when it becomes a standard.

[Grant Palin]

Here's what I'm using.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">

[Grant Palin]

I double checked, that's what's in place. There should be no problem.

[jkd]

Originally posted by oracleguy
And plus, if you start now you it will be much easier for you when it becomes a standard.

*cough* XHTML 1.1 is a standard fyi. So is XML 1.0, etc.

[hairynugs6382]

I was wondering if XHTML is better does it require all the same know how of html? And when you say it has the stricker syntax you mean <body bgcolor=blue> will not work but <body bgcolor="blue"> will?

[ddubs]

Originally posted by hairynugs6382
I was wondering if XHTML is better does it require all the same know how of html? And when you say it has the stricker syntax you mean <body bgcolor=blue> will not work but <body bgcolor="blue"> will?

i dont' know anything that i thought i did!!

[jkd]

Neither is valid.

The former because it is invalid XML, the latter because the bgcolor attribute is deprecated (or removed, can't remember).

Use CSS:

html, body {
background-color: blue;
}

[ddubs]

Originally posted by jkd


*cough* XHTML 1.1 is a standard fyi. So is XML 1.0, etc.

stadard as to what? xhtml over html? or xhtml peroid?

html, is a thing of the past then...wow there is alot of work to be done out htere lol:confused:

[hairynugs6382]

So then you keep saying XHTML is XML does that mean its based on XML or does it mean they are one. should I learn XML as well?

[jkd]

XHTML 1.1 is a W3C (http://www.w3.org) Recommendation, otherwise known as a standard.

XHTML is an XML Application, i.e. a well-defined application of XML with well-defined "behavior" of tags. <p> is known to be a block-level element. <img/> is known to display the image located at the url given in its "src" attribute as content. etc

Other XML applications include (but are not limited to) SVG, MathML, XSLT, XSL-FO, RDF, RSS, XUL, and XBL.

[hairynugs6382]

OK cool I tried it and saved it as a .xhtml extention and it did not work. Then I saved it as an .html and it worked is this the correct way? Thanks for answering my other ? as well!

[jkd]

Extensions mean nothing. It is all in the mime-type.

There are currently several ways to serve XHTML:

1. text/html (extension is .html or .htm usually)
This is backwards-compatible and invokes the HTML renderer of the browser, not to mention the most common, but incorrect way of doing it. Some XML-specific features of XHTML will not work with this mime-type.

2. text/xml or application/xml (generally .xml)
This invokes the XML parser, and is perfectly valid. Unless IE sees a stylesheet though, it will show the DOM tree instead of the rendered document because it is a stupid browser.

3. application/xhtml+xml (typically .xhtml)
"More correct" than the previous (not really, but I consider it so), and identical behavior. If you have NS6+ or Mozilla installed, .xhtml should be registered to this mime-type.

[hairynugs6382]

Ok I'm lost!

[jkd]

On...?

"What are mime-types?"

"What do mime-types have to do with serving documents?"

or

"None of the above."

? :)

[ddubs]

all of the above...

you are a smart kid....

I always lose focus when i hear MIME....I think my head is too blazed today.

[jkd]

In a nutshell, a mime-type is used to determine which program should be used to parse the file, watch/listen to the multimedia, etc.

The mime-type tells exactly what kind of file it is reading. image/gif, text/html, application/x-octet-stream, whatever. Programs associate themselves to particularly mime-types, and at least in Windows automatically launch when required.

[Alex Vincent]

The fun comes in configuring your server to support these "new" XML mime types. (Media types are another name for mime types.) For instance, Apache doesn't, to my knowledge, have extensions naturally defined for application/xhtml+xml

I believe you need an .htaccess file in your root web directory containing syntax similar to the following:

AddType application/xhtml+xml .xhtml (whatever other extensions you want, separated by spaces)

Incidentally, the mime type also significantly affects the Document Object Model on the browser side. An application/xml serving of the same document will have a different DOM than text/html. And Mozilla's support of application/xhtml+xml in the DOM leaves a bit to be desired.

[jkd]

Originally posted by Alex Vincent
And Mozilla's support of application/xhtml+xml in the DOM leaves a bit to be desired.

I've never noticed any differences in terms of DOM between application/xhtml+xml, application/xml, and text/xml.

Care to fill me in?

[Alex Vincent]

application/xml and text/xml aren't required to support DOM Level 1 HTML. application/xhtml+xml is.

Here's one example I discovered a while back:

http://bugzilla.mozilla.org/show_bug.cgi?id=111514

[Catman]

Originally posted by jkd
Neither is valid.

The former because it is invalid XML, the latter because the bgcolor attribute is deprecated (or removed, can't remember).

Use CSS:

html, body {
background-color: blue;
}

Or probably:

html, body {
background-color:#0000FF;
color:#FFFFFF;
}

[oracleguy]

Originally posted by jkd


*cough* XHTML 1.1 is a standard fyi. So is XML 1.0, etc.

I was refering to when HTML is no longer supported or it isn't the "norm".

[brothercake]

This MIME stuff .. does that mean that without the AddType directive Apache will not server XML pages correctly?


I would caution from my own experience that XHTML doesn't cover everything - there are situations where you have to abandon the standards in favour of proprietary hacks. Not many though - I know of two:

- <object> is not recognised in all version of netscape 4; if you want flash objects to show up you still have to use <embed> as well

- CSS body margins are problematic, because in mac/ie5, opera 5 and 6 returned values for offsetLeft and offsetTop of an object do not account for the margins. This can cause a problem with absolutely-positioned layers being in the wrong place.

[ddubs]

Originally posted by oracleguy


I was refering to when HTML is no longer supported or it isn't the "norm".


I thought so oracleguy...that threw me off a bit too.

[ronaldb66]

I would caution from my own experience that XHTML doesn't cover everything - there are situations where you have to abandon the standards in favour of proprietary hacks.
That's not a standards problem, that's a non-standards-compiant-pig-headed-we-do-what-we-like-to-ensure-sales browser problem...

[brothercake]

perhaps; but it's still a fact; something to consider.

[ronaldb66]

Of course you are right; sad but true. I read a piece on A List Apart about their efforts to make a DIV based layout work on as many browsers as possible using "feature-support" detection; enough to give you a serious craving for an aspirin...

[Jerome]

The advantages of using external XML-files as a database was one of the reasons which decided me to set focus on the actual programming.

XHTML-strict was the target, so iframes etc. where abonded, everything in favor of the latest standard.

Nice, however, after some time a lot of questions start to rise, f.e.:

Q1.
The way of retrieving an external XML-file, mentioned in one off the javascript-kit tutorials is not a valid XHTML-way, no, the question is: is there a w3c-standard to retrieve an external XML-file? Will there be a standard for this?

Q2.
I have no possibility to own my own server (and I don't speak about configuring one myself!) So You need to have an account which supports the correct mime-type for xml and support activeX. What I understand from Alex Vincent that's where the real problems start.

This reply should be sounding positive!!!!
Jerome

[liorean]

Jerome:
Hmm, I would think xml as a database is not that very good - there are hierarchical databeses or even xml-based databases for Java, C/C++ and LISP that are much better on this aspect. Especially nice is that fact you can use XQuery/XPath for data retrieval instead of SQL, which isn't suited for handling hierarchical data.

A1: As for the W3C Standard, yes there is, but just not yet. It's called [DOM3 Load & Save] and can be used as Mozilla XMLSerializer/DOMParser and Microsoft XMLDOM/outerHTML. It can't however be used as XMLHttpRequest/XMLHTTP. It's also not able to reach cross-domain, because that is the security level ECMA recommends on JavaScript, which is one of the major DOM enabled languages.

A2: .htaccess in Apache can be used for this, if enabled, and there are equivalents for other servers. I don't see why you would need ActiveX on the server to be able to use it. You could use any server-side language for these means, as well.

Alex:
As for Mozilla having problems with 'application/xhtml+xml', can you give me any examples? It parses like xml, so it doesn't use HTMLDocument but Document instead (which is perfectly valid behavior for any '+xml' content type), but other than that, I can't find any problems with it. It's got a very thorough knowledge of the xhtml namespace, and it's conforming to standards when it comes to encoding.

(HTTP before XML before MIME, which is questionable since XML can contain information that otherwise would be in the HTTP)

[cg9com]

I'm all for strict XHTML, It's all im writing now.

However I think that a 'loose' HTML is vital, sure the internet is filled with bad coding from it, and bad habits are developed, but not by anyone who takes markup seriously.

the simplicity of basic (and sometimes invalid) HTML is what makes the internet so popular.Some people just want to make a page about there pet dog or something, without having to learn about standards compliant blah blah blah XHTML2 CSS3.

My 2 cents.

[Alex Vincent]

Resurrecting old threads from the graveyard, eh? I'm game. :)

The problem is that app/xhtml+xml should support the HTML DOM as well (to an extent -- I'll come back to that). For instance, document.forms is an extension from HTML DOM Level 1 that until recently Mozilla builds did not support for application/xhtml+xml.

This has changed, thanks to Johnny Stenback. Please note bug 111514 at Bugzilla (link given in my last reply to this thread) for details.

As for limits of HTML DOM support: there are restrictions on that support, particularly for document.write(). That statement is specifically disabled during the loading of a page. The write() and writeln() methods can create non-well-formed XML markup in the midst of a well-formed XML document, and that's a Bad Thing.

[liorean]

Well, that's what I was talking about - you aren't required to apply anything other than [DOM Core] for any '+xml' content type, so using Document instead of HTMLDocument (which has the member collection forms) isn't in any way wrong - in fact, no web author should take for granted that a document is parsed as any special DOM (MathML, SVG, HTML etc.) Document when sent with any 'xml' or '+xml' content types. (Since XML hasn't got any script inclusion mechanism you shouldn't take loading and running scripts for granted, either.)

As for using docuyment.write, I agree with you to a certain point, but I believe that if you use [DOM HTML] you should go all the way; and if it outputs invalid XML, you should handle it as you would handle invalid XML; you should halt the parser and announce the error as were it written directly in the source code. (There is a W3C statement somewhere - I can't remember exactly where - that a document is valid only if it is valid after finished parsing, modificating, and loading, and that eventual further modification should not allow construction of invalid code.)