Subscribe: Comments on: Why it’s OK to send XHTML as text/html
Added By: Feedage Forager Feedage Grade B rated
Language: English
abbr abbr  abbr  blockquote  code text  code  content  document  don  people  send  svg  text code  text  xhtml abbr  xhtml  xml 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments on: Why it’s OK to send XHTML as text/html

Comments on: Why it’s OK to send XHTML as text/html

You've got your good thing, and I've got mine

Last Build Date: Wed, 01 Jul 2009 08:49:07 +0000


By: Michael

Wed, 01 Dec 2004 22:37:33 +0000

Why use XHTML? It is a step in a good direction. It does teach new developers consistency. It also helps them understand where boundaries are and how elements belong within the structure of a document without needing to explain that the parser can figure out the ambiguities for them and here's how it does that... It allows the content developer to serve content to newer more robust user agents and to some degree be future proof while at the same time through simple mime-type negotation send out the same content to non-comformant user agents. It can do this without the need for additional processing - i.e. regenerating the whole page as html. It allows some companies to reduce the number of internal "standards" documents that they have to maintain - instead of saying "Okay we're going to use HTML 4.01 but we're going to close all our tags, lower case our elements and quote all tags blah blah blah blah", they can just say "We're using XHTML 1.0 - see the W3C". Partner that aspect with an XHMTL validator and code reviews are quicker. XHTML modularization, predictability, removing some of the old HTML debris,... on and on. For me XHTML has been easier to teach and reduced a significant number of problems for page development, data delivery, and browser bug issues. Your mileage may vary. If you don't like it great, don't use it. Don't call someone an idiot because they believe that it helps their development process or they get some perceived benefit from it instead of going through some parallel path to get HTML 4 to do the exact same thing. I'm personally sick to death of the XML/XHTML/HTML4 haters that go back and forth treating each other as if the other group is the biggest idiots in the world because they don't see the other way as best. It's like a clash between Atheists and Southern Baptists or JAVA vs. C++. The argument here so far is "There's no benefit from sending XHTML" and "There's no benefit from NOT sending XHTML". You get the HTML4 people saying "why not just close your tags" and the XHTML people are "if I'm closing all my tags why not just use XHTML". While I'm not going to tell anyone to blow me I think Ricardo brings up an interesting point - use what works for you, your development process, and your target audience. I'm happy there are people out here educating others, who don't generally know, about the benefits and sometimes the cons of web standards. Unfortunately for every person who's out here trying to apply logic and generally trying to make things better, there are fifty people with their books held high in the air screaming at the top of their lungs "SINNER!".

By: Ricardo Carrasco

Wed, 01 Dec 2004 01:27:59 +0000

I rant the light fantastic about tables(Mommie Dearest - "No Tables Eveeeer!") InnerHtml oh so improper, Get over yourself, Man. These web purists are dull and unimaginative, if a table works, I'm putting it in, If I have to use a hack, I'm putting it in, If I have to use innerHTML, I'm putting it in, what are people going to get sent to jail? You can only take accessibility so far before it defeats the purpose of a page SOMETIMES. If css zengarden is all there is, you can just blow me.

By: Jacques Distler

Thu, 11 Nov 2004 05:36:08 +0000

Adobe's SVG plugin works only with SVG content included via the element. I use plenty of that on my blog. All my illustrations are done as SVG, with a GIF image as a fallback. Adobe's plugin does not work with inline SVG content. On another matter, can someone explain to li'll ole me why "closing all your tags" (in an HTML document) is supposed to make you more virtuous, your content more accessible, or have any positive benefit whatsoever. The closing tag of the

element (for instance) is optional in HTML for a very simple reason: it is unambiguous that a

element ends when the parser encounters another block-level element or the close of the

's parent element. If there's no ambiguity where an element ends, no information is lost if you omit the (optional) closing tag. But there seems to be this ubiquitously-repeated canard that there's something "wrong" with HTML because it allows you to omit the closing tags of some elements (like

). XML is, of course, a whole different story. An XML parser doesn't know a "block-level element" from a hole in the wall. So it can't rely syntax to determine document structure. But people who don't give a rat's ass about XML seem to persist in the assertion that there's something broken about the syntax of HTML, that's fixed in XHTML ("You have to close all your tags."). Why is that?

By: Paul Connolley

Mon, 08 Nov 2004 16:04:02 +0000

Everyone here agrees with you that HTML is not XML.
And thus an XHTML document which is served to the client application as a HTML document is considered not to be XML either. It would work in any browser with a suitable SVG capability. In MSIE it would work with the Adobe SVG plugin (but, presently, only as an embedded object), Mozilla support varies. I remember one implementation of Firefox which definitely didn't have SVG support. I now work on Mac OS X so I don't have much opportunity to test such things very often. I haven't a sample page because I am waiting for more support before I start testing it. My blog is my testing ground so I would normally go straight ahead and do it but I want to wait for better browser support (plus I can't say that all of my creations are quite up to scratch yet). Jacques Distler's blog is a better example of extending XHTML with another markup language.

By: Geoff

Mon, 08 Nov 2004 14:55:15 +0000

By declaring a namespace, you can insert an entirely different dialect of XML into your XHTML document.
Right, do you have an example of an SVG element embedded in a page anywhere? Are you using Adobe's plugin to render the SVG content? I'm guessing it would only work in Mozilla and maybe Opera?
Well-formedness is an XML concept and nothing to do with HTML.
Paul this is exactly my point. You keep bringing up arguments that have nothing to do with what we are talking about. Everyone here agrees with you that HTML is not XML.

By: Paul Connolley

Mon, 08 Nov 2004 12:37:43 +0000

With regards to SVG: XHTML is a reformulation of HTML in XML. Do you understand what capabilities XML has? XHTML is designed so you can extend its function through additional namespaces. By declaring a namespace, you can insert an entirely different dialect of XML into your XHTML document. This ties in with what I wanted to say about backwards compatibility. XHTML is very limited if all you are ever going to do is serve HTML. You also mention that HTML doesn't enforce well-formedness. Well-formedness is an XML concept and nothing to do with HTML. Missing end tags are permitted in HTML because it is permitted. If you believe it is not well formed then remember that it is HTML not XML. I refer you to a comparison of SGML and XML. Whilst it is a handful to read, the point I wish make is that SGML and XML follows a different ruleset.

By: Faruk Ates

Mon, 08 Nov 2004 11:45:42 +0000

Mike D:

Very well said Geoff. I agree with 100% of what you’ve written here.

I essentially said the exact same thing as Geoff did here, but you didn't agree fully with me. Why is that? You still haven't told me what parts of my two articles (well, article and Log post) you disagree...

By: Robert Wellock

Mon, 08 Nov 2004 09:52:26 +0000

Though my eXtensible "embed" element is suitable for XHTML albeit my DTD was a little tatty. The plugin I were using a few years back when I was playing with SVG was the; Adobe SVG Viewer 6.0 (beta) for obvious reasons.

By: Tommy Olsson

Mon, 08 Nov 2004 07:01:51 +0000

If you serve XHTML as text/html, you will still get away with not closing elements, not quoting attribute values, etc. Yes, the validator will tell you, but user agents will happily render this as the tag soup it is. As long as you're serving text/html it isn't necessary to close certain elements. It isn't necessary to quote all attribute values. Why? Because it's HTML as far as user agents are concerned.

By: Geoff

Mon, 08 Nov 2004 03:07:43 +0000

If I were to send a portable network graphic (.png) with a Content-type header of image/gif would I truly expect the client program to treat it as a png?
This is a terrible comparison. First, XHTML was designed to be backwards compatible with HTML. There's an entire appendix to the specification that gives the details on this (which i'm sure you are well aware of). I'm not going to go check, but I'm pretty sure that the png specification doesn't say 'you may send a .png file as .gif and be ok.'
The XHTML accessibility dream is a misnomer. If you can’t manage good semantics in HTML you ain’t gonna get it in XHTML either.
This is another terrible argument. Do you really think that a non well-formed document is going to be easier to read by a screen reader than one that is well-formed? It seems to be common sense to me that any user agent would have an easier, more predictable time with well-formed documents than not. Now with that in mind, if I have a team of 'HTML coders' working for me, and I say 'make it XHTML 1.0' [and enforce validation], then I know my pages will be well-formed and won't contain any strange things that could throw off some random user agent because a tag wasn't close somewhere.
You mention of validation is fascinating. The HTML specifications should highlight enough information for you to create a valid and strict document.
Actually, the HTML 4.01 validator won't tell you a lot of things, like tags you forget to close, or non-quoted attributes, or any of the other requirements of XHTML that aren't in HTML. If you are sending pages as application/xhtml+xml you'll notice these mistakes pretty fast via the 'yellow screen of death.' But if you have an entirely text/html website wouldn't it be better to validate your pages as XHTML 1.0 so you are alerted to malformed markup or other mistakes? As for your SVG stuff, I'm actually quite interested in how you are embedding them in your documents... are you using the Adobe plugin? Do you have a sample page with any SVG stuff on it? I was very surprised to find that the SVG animation examples on the w3c site were all using embed tags, which I'm sure you are aware don't exist in XHTML.

By: Paul Connolley

Mon, 08 Nov 2004 01:55:03 +0000

You’re comparing mime types… that’s not what this is about - the question is “if you can’t [or don’t want to for some reason] send application/xhtml+xml, what do you send as instead?”
But this issue is most definitely about 'Content-type.' If I were to send a portable network graphic (.png) with a Content-type header of image/gif would I truly expect the client program to treat it as a png? The client would treat it as a gif because the server said so. To presume otherwise would be illogical. Before you retort by claiming that html and xhtml files are the same thing you are mistaken. Stop talking about mime-types and content-types. They are a method, implemented by a server, to tell a client application the type of document being sent. If you are a windows user, this is equivalent to looking at a file extension to determine file type. So... If a server tells you that it is sending an xhtml file, it is to be treated as such. If it says it is sending a html file it will be treated as such. Both are plain text files. So are .h and .c and .pas files.
Another thing to add here is that some screen readers will traverse the DOM when reading a document, so using valid XHTML over possibly invalid HTML could easier access to your content.
The XHTML accessibility dream is a misnomer. If you can't manage good semantics in HTML you ain't gonna get it in XHTML either. It makes me feel giddy to say it but I've seen more accessible websites written with tables for layout and marquees and javascript menus. By goodness they sucked visually but screen-reader and text-only browser alike they looked fantastic. Semantics, bandwidth saving and valid code are just as doable with HTML.
Yes, but not on the same level. If I forget to close a tag the HTML validator won’t tell me. If I forget to quote an attribute it won’t tell me.
Well-formedness is a new concept introduced by [XML]. Essentially this means that all elements must either have closing tags or be written in a special form (as described below), and that all the elements must nest properly. [From XHTML 1.0 2nd ed. - Sect 4.1]
So, forgetting to close a tag doesn't matter does it? No because it is a subset of SGML. If you don't close a
tag it doesn't matter either because HTML is an SGML subset. HTML is not XML. You mention of validation is fascinating. The HTML specifications should highlight enough information for you to create a valid and strict document. I notice that you use a transitional doctype. The XHTML Transitional doctype permits the use of presentational markup to be used. My advice (in general) is that you (the royal you) look to separating presentation from markup. That is a strict and accessible goal which can be achieved through HTML and CSS. Using XHTML should be for a specific reason. There are very few who actually use it because they have a need to extend their HTML. I hope to start popping some of my SVG creations on my personal blog (once I'm assured that people can see them). Jacques D is another who makes use of the eXtensibility of XHTML. Without extending your XHTML document are you wasting your time? It's an issue which people (learner web dev teams) should consider before plowing ahead.

By: Geoff

Sun, 07 Nov 2004 22:39:32 +0000

And what’s really important is still the case that the wrong MIME causes the browser to render tag soup, which is what we’ve been trying to avoid using web standards…
You're comparing mime types... that's not what this is about - the question is "if you can't [or don't want to for some reason] send application/xhtml+xml, what do you send as instead?"

By: Rob Mientjes

Sun, 07 Nov 2004 22:31:00 +0000

I think Mark has a strong point. You should better use semantic HTML than XHTML sent as text/html. There is no point in saying that using HTML blocks progression, as many people do. And what's really important is still the case that the wrong MIME causes the browser to render tag soup, which is what we've been trying to avoid using web standards...

By: Tommy Olsson

Sun, 07 Nov 2004 17:47:46 +0000

Gez, of course. I just knew someone would misinterpret that one. Of course I validate. What I meant was that I find well-formedness error even before I validate the page.

By: Gez

Sat, 06 Nov 2004 19:22:12 +0000

because then I get instant feedback (e.g. the Yellow Screen of Death) in Mozilla if it’s not well-formed. I don’t even have to validate.
Validation is still required if you want to test conformance, but the yellow screen of death is useful for catching errors in documents that aren't well formed.

By: Geoff

Sat, 06 Nov 2004 17:46:26 +0000

I think you should use HTML 4.01 Strict and write it as if it were XHTML as far as possible.
I understand your reasoning for this, but I'm saying that XHTML is better than HTML when sent as text/html. Again, everything else you are saying I agree with. Send your pages as application/xhtml+xml if you can, but the minute you have to fall back to text/html, there is nothing wrong with sending those pages with an XHTML doctype.

By: Tommy Olsson

Sat, 06 Nov 2004 16:43:07 +0000

Geoff, you are encouraging people to serve HTML. Serving anything as text/html means that user agents must parse it as if it were HTML. That (and the fact that no browsers implement SHORTTAGS correctly) is why you get away with your method. OK, I understand your reasoning now, I think. Stricter validation. Fair enough. There are some instances where you could get away with malformed code if it were validated as HTML. Personally, I think it's even better to serve it as application/xhtml+xml, because then I get instant feedback (e.g. the Yellow Screen of Death) in Mozilla if it's not well-formed. I don't even have to validate. So not even that point is really in favour of your way. :) I disagree with you on the point where you say that it's better to serve XHTML as text/html if you cannot serve it with the "proper" media type. I think you should use HTML 4.01 Strict and write it as if it were XHTML as far as possible. Lowercase element names and attributes, quote all attributes and don't minimise them, close all elements where a closing tag is permitted. However, it's a matter of opinion, and I can't claim being any more right in this than you are. My main fear is still that people will do it "your way" and never learn XHTML properly. Then they may blame the standards when it stops working in the future, if they should happen to change the media type. So we'll agree to disagree? :)

By: robert

Sat, 06 Nov 2004 00:14:41 +0000

Why you can't validate your html documents with the webdev toolbar??? I think it's better to send valid html than sending valid xhtml with the wrong mime-type, because xhtml just isn't backward-compatible. Even if the recommendations say so. A browser has to make something of your tag-soup because xhtml != html. And that is what you're doing, telling the browser to parse xhtml as html...

By: Geoff

Fri, 05 Nov 2004 16:26:18 +0000

Tommy, I mostly agree with you - it is important for people to understand the differences between the different mime types and how they behave. The point I'm trying to make is that if for some reason you can't send your XHTML as application/xhtml+xml, then it's perfectly acceptable to send it as text/html instead of reverting all the way back to HTML. That's all. I'm not saying HTML is a bad thing at all, and I'm not encouraging people to serve it (where did that come from?). What I am saying is that if you cannot send your XHTML content as application/xhtml+xml then it's perfectly fine to send it as text/html. It doesn't hurt anything, and it's better than HTML because you have stricter validation rules, which make creating your well formed documents easier (everyone agrees that well-formed documents are better than non, right?). As a developer, it's easier to validate XHTML content. I can just hit my validate button on my web dev toolbar and figure out whatever is wrong with the document. If I were using HTML, I could have have a malformed document and the valdation tools wouldn't tell me (unless I tell it to validate as XHTML, but then why not just use an XHTML doctype?). The only part where we disagree is in telling people to use HTML instead of XHTML when sending them as text/html.

By: Tommy Olsson

Fri, 05 Nov 2004 15:22:17 +0000

As Robert said, I don't claim that it is wrong to serve XHTML as text/html. I'm just saying that there is no point in doing so. You assert that this is misleading. Could you please explain why? What are the benefits of using XHTML if you don't serve it as XML? I'm not being facetious, I truly don't understand it. If you think that HTML is a bad thing, why do you encourage people to serve it? The reason I'm trying to raise this issue every once in awhile is that there are lots of beginners who do not know the differences between HTML and XHTML. They think that it's only an issue of using lowercase tags, quoting attributes, and closing all elements. These things can be done in HTML as well (with the exception of a few element types). Serving XHTML as text/html means that those beginners can make mistakes out of ignorance, such as enclosing style rules and scripts with SGML comments, using document.write() etc, without realising that it shouldn't work. Because user agents interpret the document as HTML, as Anne explained. Then one day in the future they decide to "do it right" and serve it as application/xhtml+xml. All of a sudden their entire site stops working. They get the Yellow Screen of Death in Mozilla, or their fancy JavaScript menu doesn't work anymore. What happens? They blame the standards that "don't work". That's why I think this practice may be harmful to web standards. If you're experienced and educated and know about these issues, you can definitely serve valid and well-formed XHTML as text/html if you feel like it. It doesn't hurt (much). You gain absolutely nothing, though.