Those two are mutually exclusive, I’m afraid. The only reason pretend-XHTML works is due to browser bugs. I don’t know about you, but I would feel bad about relying on bugs.
No ‘big guys’ who know what they are talking about recommend XHTML. Some did a few years ago (before they knew what they were talking about). XHTML is dead. It is also very poorly suited for web pages.
Great! I applaud that effort. It has absolutely nothing to do with XHTML vs HTML, though. On the other hand it has everything to do with Strict vs Transitional, i.e., the separation between content (HTML), presentation (CSS) and behaviour (JavaScript, DOM).
I’m staying with HTML 4.01 until Internet Explorer is capable of interpreting XHTML.
For some reason though I feel that I should be saying “I get 40 rods to the hogshead and that’s the way I like it”, but with Internet Explorer only understanding HTML, and not XHTML, that’s the way it has to be.
It’s either that or you write no-standard XHTML so that when served to Internet Explorer as HTML, it can interpret the non-standard XHTML as if it were HTML in the first place.
You have had your question already answer several times. However, I’ll reiterate, for simplicities sake; you’e decided you aren’t be going to be using any client-side scripting… So that makes things easier; you write whichever you want. But you know Internet Explorer cannot deal with XHTML as ‘application/xhtml+xml’ and that’s the “main point” whereas every mainstream browser can understand; ‘text/html’.
Thus you can write HTML; no issues, “well-formed” XHTML (text/html) no major issues, or XHTML as an Application of XML (either to all, or detect for browsers that can) no major benefits in most cases - but the correct way to serve XHTML.
Do whichever you want but beware of the pitfalls of Legacy browsers should you ever use and serve: x(ht)ml.
I think you are getting “confused” with the fact most people who author XHTML wouldn’t know what it was; even if it hit them on the head. Most don’t even go to the bother of checking for “well-formedness” in the first place.
As-long as you understand; XHTML 1.0 only “mimics” the appreance of HTML but is not really HTML in any shape or form it will be easier.
As long as your coding requires supporting Internet Explorer, you should code in HTML 4.01
If you code in XHTML you will be severely limited to only coding that which Internet Explorer can interpret as HTML anyway, so there’s no benefit in coding as XHTML.
HTML 4.01 strict is what you should be coding with.
Everyone who thinks otherwise needs to read this article by David Shea (aka, Mr Zen Garden).
Off topic: I read some comments on this forum a while back by Stephen Felgall. The guy said that if you’re using XHTML and you want to use Javascript to initialize a function (ie, x.onclick=function (){}), you need to use an onload event handler. In other words, the function can’t be initialized until the whole page has loaded.
However, according to Mr Felgall, this is not the case with HTML as functions can be initialized immediately or progressively or sequentially.
Can someone please confirm that my understanding of Stephen’s comments is correct.
When properly served as real XHTML in a web browser other than IE (since IE will just offer the file for download) the XHTML DOM is not available to be accessed by JavaScript until after the entire page has loaded. You cannot therefore access anything in the DOM just by placing the code that does the access later in the HTML than the element it accesses the way you can with HTML.
Also when referencing XHTML you need to use the namespace versions of the DOM commands. Also some JavaScript commands that work with HTML such as document.write and .innerHTML do not work in XHTML.
While you can write XHTML that looks similar enough to HTML to be able to serve it as HTML, if you serve it properly as XHTML then the JavaScript code to access the XHTML DOM will be different from what you would have used to access the HTML DOM.
I don’t know for certain just how well that patch works for allowing the page to be served as XML. Must add that to my list of things to test. If it does work for serving pages as XML and has them looking the same as if they were XHTML then that would be a partial solution to getting XHTML to work on IE but you’d still only be able to use a subset of XHTML. You’d still have to write completely different JavaScript to interact with the X(HT)ML to what you would with HTML. I can’t think of any situation where it would be worth the effort.
No, you should be designing pages using strict (if possible), transitional exists for compatibility with old code (or when you can’t serve it properly).
re:Although that assumes you are actually serving ‘Real XHTML 1.0 Strict’, which SHOULD really be ‘application/xhtml+xml’ as it is not “backwards compatible” unlike Transitional.
Are you saying we should be designing pages in transitional and not strict as it’s not backwards compatable?
Those with Internet Explorer can still see XHTML web pages, just not in IE itself. IE kindly offers such pages for download where the person can then view them in whatever program they have available to view XHTML in - there are plenty of free programs available to use as XHTML viewers.
What you had above but just omitting the <?xml version=“1.0” ?>, it’s the bit I’m suggesting you omit that can cause all sorts of chaos within Internet Explorer.
If you want to be backwards compatible with Internet Explorer 8 and earlier then you should be using an HTML 4.01 strict doctype in place of the XHTML one.
I wouldn’t include the XML Doctype above the DTD because in Internet Explorer (early versions) it can trigger quirks mode (that and unless your serving application/xhtml+xml as the MIME type - which no IE version supports - not properly anyway… it’s technically inaccurate).
yeh , thats what I thought but I didnt know what exactly the bugs were. So if you dont include the statement why does it recommend you do ? dont you need it for xhtml strict
