In Stuart Langdrige’s book DHTML Utopia he says the following:
Most importantly for this book, XHTML makes using DOM scripting pretty
awkward. The HTML collections document.images, document.forms,
document.links, and so on, do not exist in many browsers’ implementations of
the XHTML DOM. Arguably, one should avoid using these anyway in preparation
for XHTML later. Instead, you must use document.getElementsByTagName appropriately.
The element names in the DOM are also case-sensitive (and always
lowercase, since XML element names are lowercase and XHTML is XML). That
can be a bit of coding style trap. You also can’t use document.write at all, although
you probably should avoid it anyway, for reasons I’ll explain in this book.
These are not major problems, and if you’re into standards then most of these
issues won’t affect your code anyway, but a final issue remains: you can’t use
document.createElement to create new elements with the DOM. Instead, because
XHTML is XML, and therefore supports namespaces, you must create each element
specifically within the XHTML namespace. So, instead of using
document.createElement(‘a’), to create a new a element, you must use
document.createElementNS(‘http://www.w3.org/1999/xhtml’, ‘a’).
This suggest to me that I should code any Web pages that I want to include JS with, in HTML 4.01.
On the other hand Jeremy Keith’s book DOM Scripting uses XHTML 1.1 coding examples and he says to use XHTML.
I can code and am happy to code in either really. I’m not really bothered. But I’m just learing JavaScript from both of these books and I would like some confirmation on what they’re trying to say to me (the reader) and what real difference does it make and will these issues affect me.
Bearing in mind both books were published in 2005 and since then we’ve had IE7 and IE8 and other browsers updating and cropping up.
Help would be appreciated to clear this confusion up for me.
Good question. Thinking about this makes me realize how much I don’t know.
I have no problem using “getElement” instead of “document.tag” and in fact I like it better as it seems more “right” to me. No problem when the script is working with a DOM I also wrote (I am “into” standards), but that explains the “to lower case” lines I’ve seen in other scripts.
And I don’t like using “write” so I don’t (I use alert for debugging). Interested note, the Google tracker code uses “write” and needed to be hacked to work in my site’s pages. No “https”, so no problem for me there.
I have often wondered about the “NS”. I have never used it, but it may be only needed if you want the script to work with the new element after it’s created. At least I’ve never tracked it down as the cause of any bugs in my scripts.
One thing to remember is that Internet Explorer 8 doesn’t understand XHTML so if you want your page to work in IE you have to use the HTML DOM in your JavaScript.
If you are using XHTML then you must use createElementNS and similar XHTML DOM calls that allow the namespace you are working with to be specified. If you care using HTML then you can’t use those calls since HTML doesn’t have namespaces. That means that it is just about impossible to write JavaScript that will work with both HTML and XHTML at the same time and so that means that for web pages you must use HTML because otherwise no one using Internet Explorer will be able to access your pages.
Basically there are two different DOMs that JavaScript can use - one for HTML that allows createElement, innerHTML and even antiquated calls like document.write - and one for XHTML that only allows createElementNS etc. You can’t mix the two types of DOM calls in the one JavaScript since the JavaScript has to be written to work either with HTML or with XHTML and there is no way for JavaScript to tell which of the two markup languages is being used so it can’t make the decision between them. You’d have to swap out the entire JavaScript using server side code if you were going to serve HTML to IE and XHTML to other browsers.
Well the simplest solution is to just use HTML for the web page in all browsers since all browsers support HTML. That way it isn’t messy at all.
The only time you should consider using XHTML is where you don’t need to worry about IE. Any of the things that can be done with XHTML that can’t be done with HTML can’t be used where you want to support IE at all and so serving pages as XHTML provides no benefit whatever unless you don’t need to worry about IE at all.
I guess I’m missing something. I wrote a slideshow script quite a while ago that I haven’t switched out to any library “box” script (yet). I serve “bad” HTML to IE and XHTML to browsers that support it. The javascript is:
function changeSpan(jsDone)
{
var newSpan, newText, para, spanElm, replaced;
newSpan = document.createElement('span');
newText = document.createTextNode(jsDone);
newSpan.appendChild(newText);
para = document.getElementById('area');
//make sure there are no more spans in the includes
spanElm = document.getElementsByTagName('span')[prevspns];
replaced = para.replaceChild(newSpan, spanElm);
}
*Note - No “NS”
It works in Firefox with no error messages and is XHTML
Perhaps Firefox is correcting the BAD JavaScript the same way IE corrects the BAD HTML. That’s no guarantee that other browsers would make the same correction to your incorrect JavaScript to allow it to work in those browsers though. There is nothing that says that the browsers have to default to the XHTML namespace if you use the wrong call and don’t specify which namespace to use.
It may also be working simply because you have only the one namespace currently in your XHTML and the code would break in Firefox as soon as you add anything to the page using a different namespace.
Even though it is working in Firefox your JavaScript is still incorrect because you are not specifying the namespace but are instead just hoping that the browser will select the right one.
I tried declaring another namespace (without a real DTD) and added a tag for it. It still worked in my versions of both Firefox and Opera with no Errors, Warnings or Messages (there were a few google-analytics messages).
So my guess is the browsers are defaulting to the XHTML namespace. Odd that they wouldn’t at least give some type of “notice” error. But I don’t like guessing much. I wrote the code before there were libraries with slideshow scripts but now I have some added incentive to swap out the code.
Quick Note: I realize this thread is more than 1 month old however, I’ve read the comments in this thread and taken some action - I’ve read some more of each of the books I originally quoted and I’ve come back to reply to the posters in this thread, very relevant to this thread. Rather than create a new thread.
I kind of understand what you’re saying felgall, and I know it makes sense and I agree with you but, It kind of doesn’t make sense to me, I mean, It’s kind of confusing.
I’ve done a couple of tests with the help of the examples given in Jeremy Keith’s DOM Scripting book and the following examples both work in IE 8.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<script type="text/javascript" src="DOMMethodsWay.js"></script>
</head>
<body>
<div id="testdiv">
</div>
</body>
</html>
With the external .js file holding the following:
window.onload = function() {
var para = document.createElement("p");
var testdiv = document.getElementById("testdiv");
testdiv.appendChild(para);
var txt = document.createTextNode("Hello World");
para.appendChild(txt);
}
Now, using the same external .js file with nothing changed I’ve changed the DOCTYPE and html element to make it a XHTML 1.0 document:
And that also works fine in IE8. Both you and Stuart Langdrige are saying that such a script wouldn’t work because for it to work in an XHTML document you need to use createElementNS (etc) rather than createElement on its own. So I’m confused about that bit. Unless it really doesn’t work…In a special sort of way that I can’t see or something. Bear in mind that all of the examples in Jeremy Keith’s book use XHTML 1.1 Strict and yet I don’t see any of the DOM Methods (I think they’re called) using the NS thing with them.
Well, it’s kind of confusing again for me. Stuart Langdrige uses HTML 4.01 files with his JavaScript whilst Jeremy Keith uses XHTML 1.1 (whether he used XHTML 1.0 or 1.1 it’s still XHTML at the end of the day). And neither of them use document.write or innerHTML to insert text, etcetera into their documents. But their JavaScript works still.
I think what I want to know is - If I’m going to use JavaScript in my Web page documents (whether I make them with HTML 4.01 or XHTML 1.0 documents) which (if any) type of JavaScript methods / properties / stuff should I use that will be cross-browser compatible? Obviously document.write is out of the window because it doesn’t allow you to separate from content. And innerHTML isn’t standardized as it’s proprietary and I don’t like using proprietary code. Should I use createElement and createTextNode along with appendChild, etc?
So does this mean that Mittineague’s JavaScript code example above is bad / incorrect JavaScript? Is there some sort of JavaScript code validator where you can check if your JavaScript is “valid” / “good” / “right” or not?
Thanks cooper.semantics, I hadn’t reached that part of the book yet by the way but a really good chapter that I found enlightening is Chapter 7: Creating Markup on the Fly which has taught me a lot.
Also, does this mean that document.write and innerHTML are incorrect and bad / invalid usages of JavaScript? I think innerHTML is because it isn’t standardized but if someone can confirm that for me, that you should never use innerHTML because it is proprietary and not a standard. But what about document.write is that a part of any standards or specifications?
Also, if using document.write and innerHTML are bad / incorrect / invalid, why do so many people use it? I’ve even seen a load of big (when I say big I don’t mean Websites with loads of content, I mean big as in big businesses and corporations) Websites use them. Or, is this case just like the MAMA report where even most major corporations and businesses don’t have valid HTML, CSS and in this case JavaScript too?
-breathes- Phew! I hope that isn’t too much for anyone to read! Help on this and more replies with confirmation would be greatly appreciated. Thanks very much to you guys that have already replied and thanks in advanced to whoever comes back here to help me!
Changing the doctype declaration doesn’t make it XHTML!
You have to serve the document with a MIME type that declares it to be an application of XML. The recommended one is application/xhtml+xml, but application/xml and text/xml will also work. That, in combination with the appropriate xmlns attribute on the root element is what makes the document XHTML. The doctype declaration is irrelevant in this respect.
So it will work in IE8, because you are still using HTML, even if it pretends to be XHTML.
Since IE8 doesn’t support XHTML in any way, shape or form, you cannot perform the test in this browser. Use Opera, Firefox, Chrome or Safari if you want to try real XHTML.
Heh, I realize it isn’t -real- XHTML because of the MIME type and how it’s served I should have said it differently
In regards to the testing in another browser that does support -real- XHTML: I won’t ever be using -real- XHTML using the correct MIME type. So will it still be the same if I test it in another browser? Or for the test to be valid would I have to make the document proper -real- XHTML and test it in a browser that allows .xhtml documents?
Differences regarding JavaScript/DOM exist between HTML and XHTML. That means ‘real’ XHTML. Pretend-XHTML is not XHTML at all, it’s nothing but invalid HTML. It will be treated as HTML by browsers (they have to!) which will create an HTML DOM without any XML namespaces. Thus you won’t see any JavaScript/DOM differences between ‘honest’ HTML and ‘dishonest’ HTML disguised as XHTML.
Then I suggest that you use an honest HTML doctype declaration and conform to the rules for that. Pretend-XHTML was meant as an intermediate step until all mainstream browsers supported XHTML properly. It offers no advantages over HTML whatsoever, and it never will.
Yes. If the document is served as text/html user agents must treat it as HTML according to RFC 2854. It doesn’t matter if it contains XHTML markup, or a Word document, or a JPEG image, …
Yes. Only then will the browser build an XML DOM with namespaces and such.
Damn you Tommy you’re so convincing using HTML 4.01 instead of invalid / fake XHTML 1.0! Not that it’s a bad thing…I just, It’s a personal preference with seeing the XHTML 1.0 Strict DOCTYPE in documents…I’m a bandwagon-er for sure. I like them extra forward slashes to close tags too. -hangs head in shame-
I’ve read all of your articles, topics and posts before including Ian Hicksons Sending XHTML as text/html Considered Harmful document. I just haven’t given up the reigns of using fake XHTML 1.0 because it’s just one of those personal little weird things. I’m biting my fist trying to tell myself to let go of XHTML 1.0 right now but I need to know what this will mean for me in using JavaScript with HTML 4.01. What are the rules that apply and don’t apply if I use JavaScript with just HTML 4.01 pages only?
I knew you’d end up convincing me one day, Tommy. I know there isn’t anything special about XHTML right now until browsers support it completely.
Heh I think I’ve managed to let go of my attachment to XHTML 1.0 now anyway, but whilst your here (or perhaps watching the thread) theres one tiny bit, but that has had a hold over my usage of HTML 4.01 / XHTML 1.0 for the most part.
Most books, even new ones, will encourage readers to use XHTML 1.0 Strict over HTML 4.01 Strict. For various reasons. And Ian Lloyd says in the HTML Reference and in his book that he encourages newbies to learn XHTML 1.0 rather than HTML 4.01. Why do these authors do this? Why do they recommend XHTML 1.0 over HTML 4.01 when it’s so…Well, bad really, cause it isn’t very good if it isn’t real valid XHTML. It certainly doesn’t help people choose which one to use!
Why don’t authors of new HTML / HTML & CSS books just teach HTML 4.01 but using good practices like using lowercase elements, etc. And the optional features of HTML 4.01, encourage readers to use them anyway as if they were required. So if they ever did want to transfer to XHTML 1.0 fake or real, it would be a pretty smooth transition. I mean, that’s what I’d do anyway.
Should I just not bother with XHTML 1.0 at all now then? Should I delete my PDF copy of the XHTML 1.0 TR and convert all my files to HTML 4.01 Strict valid documents? If I won’t be using XHTML 1.0 again, I don’t need to bother with it at all do I? Or is there something I should keep my finger on, other than keeping up with HTML 5?
Thanks for converting me! Feels good! I feel cleansed of that dirty, fake, fruadulent markup language! (At least in text/html form) Ugh! Haha
Just because you’ve written a book doesn’t necessarily mean you know more than anyone else.
I believe that Ian was under a lot of pressure from SitePoint to use and promote pretend-XHTML in the Reference (and his other book). It’s not necessarily his own decision. IIRC he switched from pretend-XHTML to HTML on one of his sites not long ago.
There are some people in SitePoint HQ who – for some reason – are convinced that XHTML is The Future. They even seem to believe that there are some mythic advantages of pretend-XHTML over HTML, although they can never specify exactly what those are. (Naturally.) It’s surprising, because these guys are otherwise very knowledgeable and competent.
I suppose it’s just a bad case of wishful thinking.
I did just that in my second book. The book is in Swedish, so the global impact hasn’t exactly been devastating, though.
And what you’re touching on there may be one reason why otherwise clever people in cold blood advocate pretend-XHTML to beginners: many seem to believe that HTML must be written as 1996-style tag soup. :-/
XHTML 1.0 strict written to be served AS HTML is almost identical to well written HTML 4.01 strict so converting your XHTML 1.0 to HTML 4.01 is just a matter of changing the doctype and removing a few slashes.
The biggest difference between them is when it comes to validation as many of the shortcuts that HTML allows need to be written out in full to pass the XHTML validator (such as HTML, HEAD and BODY tags not being optional in XHTML, all attribute values needing to be quoted, and case sensitivity).
Another difference is that provided you don’t have any JavaScript attached the XHTML can be served as XHTML to browsers that support it and as HTML to browsers that don’t. You still don’t get any of the real benefits of using XHTML in that case though so there is not really any point in doing that unless the intention is to actually drop serving it as HTML at some future point at which time it can then be gradually rewritten to take advantage of what XHTML can do that HTML can’t (eg. self closing script tags).
XHTML 1.0 is the cleanest most consistent standard for writing HTML that will actually work with browsers (XHTML 1.1 and XHTML 2.0 are even better but are not supported). Unfortunately the decision appears to have been made to move in the opposite direction with the adding of more junk to HTML 5 so as to make it the messiest version of HTML created so far.
I know that there are a large number of people who use the XHTML 1.0 doctype on their HTML because they consider it to be the cleanest most consistent version (in so far as what the validator will pick up). That doesn’t mean that it is the version that should be taught in the books since the reasons why those who choose XHTML 1.0 for a legitimate reason are not those who make up any significant fraction of those reading the books. For those people learning HTML, HTML 4.01 is the most appropriate version to teach (since for the small fraction of a percent of them who would find XHTML 1.0 to be more appropriate for legitimate reasons can easily switch after). Most of those currently using XHTML 1.0 do so because that is what their book taught and they don’t actually have any reason for using it - they really ought to be using HTML 4.01.
If you insist upon serving HTML to IE and proper XHTML to the others, you can avoid having completely different scripts by just creating wrappers for the functions that differ between JavaScript for HTML and JavaScript for XML. Example
function create_element(elname, context, ns) {
if (!context) context = document;
if (xml) {
if (!ns) return false;
return context.createElementNS(elname, ns);
}
return context.createElement(elname);
}
You’d need a way of telling the script (via the “xml” variable) what the mime type is (easy enough, since you’re the one controlling it).
There aren’t that many things you’d have to create wrappers for, so it shouldn’t be too bad. This sort of thing is often done anyway to avoid the verbosity of “document.createElement” and friends.
It’s his book! I would have thought seeing as he’s the author (him being the professional knowing what he’s talking about as he’s writing it) he’ll decide what content goes in the book. SitePoint should have known better than that me thinks SitePoint are supposed to be one of the best publishers for Web Designers / Developers, no? Doesn’t sound like that way.
XHTML 5, sure, but not XHTML 1.0, 1.1 or 2.0 - HTML 5 is the future of Web markup now, XHTML 1.0, 1.1 and 2.0 are going nowhere. They need to wakeup. They supposedly want to publish a HTML 5 book - But they don’t seem to know what the right markup language is currently. Weird.
Damn! You need to get the publisher to publish an English version then! Tell them if they publish an English version then it’ll sell like hot cakes!
Are they crazy?! HTML 4.01 can be written just as clean, tidy and strict as XHTML 1.0 can. You can write HTML 4.01 Strict valid code that’s practically identical to XHTML 1.0, minus a few forward slashes here and there. There isn’t much different, in terms of the syntax.
Aye, I understand that now. It seems I was one of those confused developers regarding HTML and XHTML. It’s a bit crappy it’s taken me this long to understand though!
That was me until today! -hangs head in shame- Kind of makes you feel like you’ve been betrayed by all those authors now. :-/ I’m using HTML 4.01 Strict documents from now on though!
I don’t need to now, I’m just going to use HTML 4.01 documents for all Web pages I create in the future now But thanks very much for the example code, Raffles.
(Almost) Lastly - If using document.write and innerHTML are bad / incorrect / invalid, why do so many people use it? I’ve even seen a load of big (when I say big I don’t mean Websites with loads of content, I mean big as in big businesses and corporations) Websites use them. Or, is this case just like the MAMA report where even most major corporations and businesses don’t have valid HTML, CSS and in this case JavaScript too? The same goes for tonnes of JavaScript tutorials on the Web, most of them make use of document.write or innerHTML. More crappy tutorials that need to be taken down off the Web?
(Definately) Lastly - Is there a Website, document or booklet (PDF or Print) that has a list of non-standard, proprietary JavaScript features that shouldn’t be used? Like, is there a Website where you can validate or check your JS code to see whether it’s valid and uses standardized JS or not?
(Absolutely) Lastly - Providing I use the supported and standardized JavaScript code and DOM Methods in my JS files along with a HTML 4.01 Strict document, will I come across any problems (browser, validation, correctness / invalid code, etc.)? Like, if I was using XHTML 1.0 (real) I’d only be able to use certain code and also would have to change some DOM Methods to add NS at the end.
(Absolutely definately lastly…Kidding ) Thanks for the help, feedback and comments guys, you’ve been really helpful and I’ve made pretty big changes in my views today and also all of my code and future markup that I’ll produce, in HTML 4.01 Hopefully I won’t come across any snags in JavaScript in the future!
but a really good chapter that I found enlightening is Chapter 7: Creating Markup on the Fly which has taught me a lot.
I would have thought seeing as he’s the author (him being the professional knowing what he’s talking about as he’s writing it) he’ll decide what content goes in the book. SitePoint should have known better than that me thinks 
SitePoint are supposed to be one of the best publishers for Web Designers / Developers, no? Doesn’t sound like that way.
Hopefully I won’t come across any snags in JavaScript in the future!