Discussion subject XHTML

[blain]

Working on the following premise.
"XHTML is a dead language as Internet Explorer doesn't support it"

Should we use it?
Is there anything you can do with (pretend)XHTML that you cannot do with HTML?
Will IE ever support XHTML?


Discuss...

[AutisticCuckoo]

Is there anything you can do with (pretend)XHTML that you cannot do with HTML?

How would that even be possible, since pretend-XHTML is HTML from a user agent point of view.

[blain]

Discuss...?

[felgall]

There are purposes for XHTML that have nothing to do with whether or not IE supports it.

Rivers don't support cars while most other relatively flat surfaces do support cars. Does that mean we should stop using cars just because rivers don't support them or should we just use a boat (HTML) where that is appropriate and keep the cars (XHTML) for the situations where they are appropriate.

[paul_wilkins]

I agree with the OP premiss. In terms of webdesign that has to support IE and other browsers, , XHTML has no benefits over HTML.

If it was plausable that IE was going to support XHTML at some stage in the future, then it would be possible to justify staying with XHTML. Until then though there is no benefit from coding web pages in XHTML.

[cipals15]

If XHTML is not a global language then i recommend not to use it.
Use languages available on all browsers.

MySQL is good because it is available in all OS. English is good because each country has atleast one person who speak english.

[paul_wilkins]

Perhaps I missed the memo about the push for XHTML.
It seems that the plan to make Microsoft wake up and provide support for it has failed.

[felgall]

XHTML is a part of XML and has a whole lot of uses outside of web browsers.

We might as well say that HTML is dead because accounting software doesn't support it.

[blain]

XHTML is a part of XML

Sorry Stephen, I'll have to pull you up there, XHTML is NOT a part of XML, it is a reforumulisation of HTML as an application of XML.

Saying XHTML is a part of XML is like saying that google sitemaps are a part of XML.

[AutisticCuckoo]

Sorry Stephen, I'll have to pull you up there, XHTML is NOT a part of XML, it is a reforumulisation of HTML as an application of XML.

I suspect Stephen was just using loose wording, but you're right: XHTML is an application of XML, just like HTML is an application of SGML (although browsers don't treat it as such). XML is a subset of SGML and, at the same time, uses some extensions to SGML (to allow for the <foo/> syntax, which would be <foo// using the default SGML delimiters).

[paul_wilkins]

It is pleasing then that we can agree that XHTML is not suitable for web browsers, especially where IE is concerned.

Granted, XHTML can used in a cut-down modified form so that it's compatible with IE, but where then is the benefit of using XHTML?

[Arlen]

I'd also like to point out that while IE doesn't at the moment accept the MIME type for XHTML (application/xhtml+xml) that doesn't mean it won't. It just means that MS knows their current implementation is crap and they want to fix that before turning the MIME type on. They left a distinct impression that if/when they had real support in place they would turn it on.

I guess the question I'd ask in all this is why let MS dictate to you what you do? If you write in, for example, XHTML 1.0 you can serve it with the right MIME type to real browsers, and serve it as HTML to fugly ones like IE8.

Any decade now HTML5 will finally get approved and the question will acquire more meaning (as in XHTML2 vs HTML5) but for right now, I just don't see why anyone would waste time on the question. Use whichever one you feel like.

[paul_wilkins]

I guess the question I'd ask in all this is why let MS dictate to you what you do? If you write in, for example, XHTML 1.0 you can serve it with the right MIME type to real browsers, and serve it as HTML to fugly ones like IE8.

because the only XHTML that we can write, if we are to remain compatible with IE, is an extremely limited version of XHTML that cannot be allowed to use any XHTML techniques unless they can be understood by and HTML parser.

In other words, the only XHTML we are allowed to do is HTML, so where-in lies the benefit of using XHTML?

[Arlen]

In other words, the only XHTML we are allowed to do is HTML, so where-in lies the benefit of using XHTML?

What features of XHTML are you darkly hinting that you want to use? (If there *are* no features of XHTML you want to use, then of course there's no percentage in using it over HTML. If there are then there are ways to work around the deficiencies of IE.)

Personally, I prefer using XHTML whenever I can, simply because the language is more rigorous. It appeals to me. That is not a reason for me to tell you that you need to use it, however.

As my earlier statement said, I seriously doubt the question is worth the time to analyse at any significant depth. Use what you like and let everyone else do likewise.

[drhowarddrfine]

Instead of getting rid of the techonology, I propose we get rid of the problem. XHTML is not the only thing IE can't and won't work with.

Does that mean we should stop using cars just because rivers don't support them or should we just use a boat (HTML) where that is appropriate and keep the cars (XHTML) for the situations where they are appropriate.

What about a duck?

[paul_wilkins]

By not using cars in rivers and instead using boats we are being more considerate of the duck and other wildlife in the river, if that doesn't break the analogy.

[paul_wilkins]

There are many features that we're missing because IE doesn't support XHTML.
XLST, XForms, Namespaces, MathML, SVG, there;s a wide range of good stuff that we're missing out on.

It does appear that an IE developer does care about the situation. Instead of forcing through XHTML in IE7 and doing a worse job on both that and CSS, they focussed fully on CSS and intend to do a proper job on XHTML a some later stage.

[felgall]

IE will not accept the following valid XHTML tag (as just one example)

<script type="application/javascript" src="myscript.js"/>

(there are two reasons why IE considers that invalid - one of which is that it doesn't recognise the valid XHTML format and the second is that it doesn't recognise the correct standard MIME type for a JavaScript file - which is why we have to use the deprecates text/javascript instead)

[not to mention that it doesn't understand JavaScript and runs it as JScript instead]

[Divisive Cotton]

So will IE8 recognise XHTML then?

[paul_wilkins]

So will IE8 recognise XHTML then?

No, IE will not recognise anything served up as application/xhtml+xml
Like always, the pages have to be served as text/html, and the XHTML has to be written so that a browser can successfully interpret the XHTML as if it were HTML.

[felgall]

No, IE will not recognise anything served up as application/xhtml+xml
Like always, the pages have to be served as text/html, and the XHTML has to be written so that a browser can successfully interpret the XHTML as if it were HTML.

And since it is just about impossible to write JavaScript that will work with both HTML and XHTML you may as well write it for HTML and use HTML instead of XHTML if you want to support IE. Of course in a year or two it the number of people still using IE will be so low that supporting them will no longer matter.

[AutisticCuckoo]

That's a fairly easy one -- if avoiding a deprecated tag is so important to you just code the conditional comments around it so IE gets the bad one. Personally, I don't see this as a reasonable issue; deprecated simply means "we're going to drop this someday" not "this is no longer valid." It's merely one step closer to the dustbin than every non-deprecated XHTML bit. My old rhetoric prof would call "text/javascript" vs "application/javascript" "a distinction without a difference."

I think you are missing the main point, which isn't the MIME type but the NET syntax. The following will also create havoc if served as text/html, and not only in IE:

<script type="text/javascript" src="myscript.js"/>

It's perfectly valid XHTML and it's the way you'd normally write an empty element in XML. But HTML parsers are buggy and ignore the NESTC delimiter ('/') – which should be seen as a NET delimiter in HTML – and will expect a </script> tag somewhere along the line. In other words, the rest of your page will not render.

No, IE will not recognise anything served up as application/xhtml+xml

Nor will it recognise XHTML served as application/xml or text/xml as XHTML, although it will parse and treat it as XML at least. All semantics are lost, though.

[Divisive Cotton]

Is there any particular reason why Microsoft won't implement XHTML? I mean it's been around for ten years now...

[Arlen]

IE will not accept the following valid XHTML tag (as just one example)

That's a fairly easy one -- if avoiding a deprecated tag is so important to you just code the conditional comments around it so IE gets the bad one. Personally, I don't see this as a reasonable issue; deprecated simply means "we're going to drop this someday" not "this is no longer valid." It's merely one step closer to the dustbin than every non-deprecated XHTML bit. My old rhetoric prof would call "text/javascript" vs "application/javascript" "a distinction without a difference."

As for some of the others: Never tried doing XSLT on the client side so I can't speak to that, but I once used it on the server side as yet another mechanism for handling bad browser behavior: I had it transform an XML file into different HTML files depending on what the user agent supported.

From the look of the feature list, it appears what I suspected is true. You're not looking for XHTML features, but rather XML features. (For example, if you use any namespace other than XHTML, then -- according to the standard -- you're no longer working with conforming XHTML documents, but other documents, such as XHTML+MathML.) Likewise, SVG is not XHTML, it's XML.

Is there any browser out there that supports XForms natively, without a plugin? Unless it's happened recently and I missed it, it's not just IE that's preventing you from using XForms.

I suspect, though, MS is not going to implement things like SVG natively at all. There are plugins for it, but MS is betting on Silverlight, and will be wanting to drive developers toward it instead of anything else. If I'm right, then your choice as a developer is to climb into the trunk and let MS take you where they want you to go or use open standards. Only you can make that choice for yourself and your clients; I certainly can't.

[paul_wilkins]

I remember when I first began writing XHTML instead of HTML. I felt manly to be using the latest and greatest, and using all of those self-closing tag techniques gave me a sense of purpose and meaning, that somehow XHTML was really going somewhere.

Now-a-days though, I have learned more and realise what AutisticCuckoo has brought up. When dealing with IE, the XHTML is in reality just badly coded HTML. And I ask myself, do I really want to write XHTML having to look over my shoulder at IE all the time and be forced to make compatibility changes just so that IE can understand it, or do I want to write strictly coded HTML that can be properly used anywhere, no matter which browser is being used.

The decisive answer to that question then becomes painfully obvious.