I was recently dragged in to an argument about whether or not it’s ok to send XHTML files with a mime type of text/html instead of application/xhtml+xml.
It seems that there are a few people spreading the word that sending XHTML documents as text/html is not only improper, but downright bad for you (gasp!). The basic argument goes something like this:
Dude[ette] sends XHTML document as
text/htmlinstead ofapplication/xhtml+xmland therefore is gaining no advantage over plain old HTML 4.01. Since XHTML ‘should’ be sent asapplication/xhtml+xml, doing it any other way is wrong and you will burn in hell. Instead you should use HTML 4.01 because more browsers understand it, and when the time comes to switch, you can just use HTML tidy or make the small changes your pages need by hand.
Ok, I added the ‘burn in hell’ part, but you get the general idea.
Now I’m not going to go into why you should use application/xhtml+xml or all the benefits and differences between that and text/html. Instead, I’m going to let you read up on the subject yourself, and then tell you why it’s quite acceptable to keep on using text/html for the time being.
All of these links are full of excellent information and everyone building XHTML websites should know this whether they agree with them or not. Go ahead and take a few moments to read them. I’ll wait here.
- Sending XHTML as
text/htmlConsidered Harmful - RFC 3236: The ‘
application/xhtml+xml‘ Media Type - Pretending to Use XHTML
Ok. Wasn’t that fun? Now here are some reasons why sending your XHTML pages as text/html is just fine. It is important to realize that the real argument here is not whether they should be sent as application/xhtml+xml or not, but what to serve as an alternative to user agents that can’t support it, such as IE.
1) XHTML 1.0 is like a gateway drug. It’s not HTML, and it’s not quite XML, but it’s a nice middle ground. It teaches you to close your tags, use lowercase attributes, always quote your attributes, never ‘minimize’ your attributes, and a few more. All of these are outlined here: The difference between XHTML 1 and HTML 4. This is a great benifit in that it teaches developers to follow stricter rules when building pages, and when the time eventually comes when they need to switch to application/xhtml+xml, there will be fewer changes to worry about than with HTML 4.
2) The XHTML standard allows you to use text/html. A short excerpt:
XHTML Documents which follow the guidelines set forth in Appendix C, “HTML Compatibility Guidelines” may be labeled with the Internet Media Type “text/html” [RFC2854], as they are compatible with most HTML browsers.
So the way I see things is that sending XHTML as text/html isn’t a bad thing at all. Using XHTML teaches developers to write well-formed documents, and teaches them the basics of XML, which will be more and more valuable as we progress from HTML to XML documents on the web. I think it’s important that people know the differences when sending documents with different mime types, but discouraging the use of XHTML sent as text/html doesn’t help anyone, and telling them there are no advantages at all is misleading.
Other reading:
UPDATE (11-10-2004): I just came across this post about content negotiation and saw an excellent conversation in the comments about converting your XHTML to HTML and the issues you will encounter.
One of the readers makes this point:
Your situation is different, though. I totally agree that XHTML should be served as application/xhtml+xml to browsers that support it. With respect to IE, you have some choices.
You could just serve it the XHTML content as text/html. Provided you’ve authored it in HTML-compatibility mode, IE will handle that perfectly well (or, at least, no worse than it handles HTML4).
Alternatively, you could decide, as you apparently have done, to serve IE HTML4, using a conversion that
1) only works with XHTML written in compatibility mode
2) runs the risk of seriously munging your text. (This is, after all, a weblog about web design!)
What’s the benefit of doing this instead of just sending IE the unaltered XHTML document (as text/html)?
And the response:
Nothing, probably. I’m reworking the “CMS” at the moment, and if I ever finish it, I will use a better system for converting to HTML. In fact, since XHTML is currently useless unless you actually need it (like your blog), I’m thinking about serving HTML 4.01 Strict to all. I’ll still store the posts as XML, though, for various reasons, so some kind of rewriting will be necessary.
So it seems to me that the optimal solution for most websites these days would be this:
- Author your pages as XHTML 1.0 strict or transitional in ‘compatibility mode‘
- Use content negotiation to send
application/xhtml+xmlpages to user agents that favor XHTML content - For user agents that don’t like
application/xhtml+xml, send them ‘compatible’ XHTML 1.0 astext/html
This way user agents that can handle XHTML get it, and if the user agent doesn’t understand application/xhtml+xml, you will have a very minimal amount of work on the server side to convert your XML content to ‘compatible’ XHTML.
Pingback: More on (x)html - Greek to me
If your total understanding of the benefits of xhtml is that it encourages developers to be better disciplined, your reasoning is fundamentally flawed and demonstrated very well on your own pages. There is nothing stopping anyone from using html without using attribute minimalization, ensuring attribute values are in quotes, and explicitly closing all tags that can be closed. Similarly, there is nothing stopping people writing ill-formed content with an xhtml doctype as you do here.
Telling people there are no advantages to sending xhtml as text/html is not misleading. There are no benefits. By doing so, you are relying on the user agent’s ability to cope with broken markup. If the whole of your argument is to encourage better practice in general, then encourage people to use the specifications properly. Telling people there are no problems with serving xhtml as text/html is misleading, particularly considering you’ve encountered them yourself but have swept them aside as you don’t feel they are note worthy. If you ever do decide to use the specification properly, it isn’t going to simply be a case of changing the mime type. The way you specify your style sheets, the content of your style sheets, the closing tags for empty elements, and the javascript you use will all require changing as you’re not following the specification.
So considering your pages aren’t well-formed, and even if they were, the approach you’ve taken would still require a lot of work before you could really take advantage of xhtml, what exactly has serving xhtml as text/html bought you?
Maybe I should have stated more plainly that there is no benefit to using HTML 4 over XHTML when you are sending your documents as
text/html, but there are benefits to using XHTML astext/html, such as the ones I mentioned above.O please. XHTML 1.0 is totally XML and when you don’t serve it as XHTML you have a hundreds things to worry about before you go to real XHTML. Just validate some sites or check the for well-formdness. About 99% of the sites that do use XHTML are ill-formed and totally not ready for XHTML.
There are more things to worry about since you always have to be sure your document is completely well-formed and the only way to do that is when your complete site is based on XML and XML related tools. Otherwise you can stop directly.
The XHTML standard shouldn’t say anything specific about MIME types. That was wrong in the first place, however, the HTML WG has stated that if you are sending your “XHTML document” as text/html it MUST NOT be treated as such and therefore must be treated as HTML, or even tag soup, since valid XHTML constructs would give different results in a SGML parser. Mostly unexpected and undesired.
And I didn’t even start about character encoding…
Ok, all of that stuff was covered in the links in my post. The question still remains: why send HTML instead of XHTML when using the
text/htmlmime type? The bottom line is there is no benefit to using HTML, and if you send with an XHTML doctype, you can at least use the w3c validation tools and have some sort of standard to give your developers or 3rd party content providers to follow.And that isn’t possible 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.
Also if you are serving
application/xhtml+xmlto user agents that support it, then you need to take out the trailing slashes on some of your empty elements if you want the HTML 4 to validate. So it could be much less work for you as the developer since you have to make fewer changes.You actually think large sites are coded by hand? The “advantages” you mention are not real advantages.
And the HTML validator doesn’t have to tell you that since it is valid HTML. And for most people that’s a good thing since you don’t want your visitors to see a yellow screen of death.
This argument isn’t about what the specifications say, as they are, in this case, purely theoratical. If you send text/html to a browser it thinks it is HTML. Therefore, even if you’re sending text which would validate as XHTML, all the browser sees is HTML and it will treat it as such. In the practical world the browser has to live in your valid XHTML is suddenly invalid HTML. That’s why it’s not OK to send XHTML as text/html.
I’m assuming you mean taking out all the trailing slashes you need to in order to get your HTML valid? My point here was not how you do it, but the fact that you have to do it at all. Sure you could write a little script that adds/removes your slashes, but why would you do that if you didn’t have to in the first place?
So what are the drawbacks to sending ‘invalid HTML’?
If you have a correct doctype all the browsers that understand them will display the page in ‘standards mode’ anyway, so you still have no advantage to using HTML over XHTML.
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. At least with XHTML you can validate your document and know that all your tags are closed and can be easily traversed.
Yes. However there are differences between XML mode and HTML mode, for example in JavaScript.
Not really, no. How is the DOM constructed, you think?
Argh, I once wrote I wouldn’t go into discussions like these… Anne, please stand in for me :-)
O please. XHTML on today’s web is almost always invalid. The points you make just don’t apply. But if you won’t accept it, just use XHTML and think you are doing the correct thing.
Very well said, Geoff.
I keep hearing this, but nobody is saying why they don’t apply.
Mark, I’m not talking about differences between
text/htmlandapplication/xhtml+xml, this is all about the difference between HTML and XHTML sent astext/html.Geoff, to me XHTML sent as text/html is worse than HTML. I’m all for clear, semantic code, but I don’t think XHTML is needed for that. And I think XHTML in it’s true form is not todays technology.
This stuff is way too subjective, however. What I’ve been seeing in these discussions is people (like Anne or me) who like a very strict interpretation and implementation of XHTML – and therefore choose HTML – and people who think XHTML stands for clean, semantic markup and a better world (sorry for the sarcasm, but I hope it illustrates my point. I’m for a better world as well, just not though HTML (I’m not very clear, am I?)).
As Paul Sowden aptly put it:
“We comply, but we don’t conform.”
And, as Edward Sowden aptly put it:
“Time is precious, hate is free.”
I’d like to conclude with that :)
Very well said Geoff. I agree with 100% of what you’ve written here. The best thing about XHTML 1.0 right now is that it teaches developers and designers to write code that is closer to the ideal. The point is not to jump over to XHTML 1.0 Strict served as application/xml in one fell swoop. The point is to get people to start writing more homogenous code. XHTML requires lowercase. That’s good. Why? Because it introduces another another level of consistency and it takes out another level of ambiguity. Programmers don’t like ambiguity and this is just another step in closing that gap.
Additionally, whoever said that big sites aren’t coded by hand is dead wrong (in a lot of cases at least). If by “big site”, you mean 10,000 pages coming from one template, fine. But my definition of big site is 500,000 pages coming from 1,500 templates.
The question still remains: why send XHTML instead of HTML when using the text/html mime type? The bottom line is there is no benefit to using XHTML, and if you send with an HTML doctype, you can at least use the w3c validation tools and have some sort of standard to give your developers or 3rd party content providers to follow.
When you use XHTML you have sticter rules to follow, which means less changes if you ever have to convert your content to be compatible with XHTML sent as
application/xhtml+xml.I answered that in my post.
I guess it comes down at how people interpret XHTML.
If you think you are using XHTML when your document validates as XHTML because you’ve used a XHTML DTD, yet served as
text/html, you are wrong.Basically there aint no difference between XHTML and HTML this way except for the end tag in empty elements.
A bigger difference is serving that same page up us
application/xhtml+xml!You don’t need XHTML to write validating, clean, semantic, ‘well-formed’ documents, nor should XHTML teach you how to write such documents.
I do, however, agree that a validator comes in handy if a XHTML DTD is used.
But just because HTML is not a strict and clean language, does not mean you are not allowed to write strict and clean HTML.
Just imagine that you were already writing validating, clean, semantic, ‘well-formed’ documents before the XHTML ‘hype’ and perhaps you might have a different opinion then.
Bollocks, it teaches them nothing. I bet you all my HTML code is better-formed and more semantic than most so-called XHTML documents on the web. If you code proper, clean and semantic HTML, the switch to XHTML quick and painless.
If you need to support browsers that don’t support XHTML, use HTML. It can be just as clean and semantic as XHTML.
With respect, Geoff, you’re proving that this really isn’t the case. Your markup will require changing if you ever decided to deliver your content correctly. If this site was written in valid, semantically correct HTML, you would have an equal amount of work to do to conform to XHTML.
I’m not trying to talk anyone out of using XHTML. I would just encourage those that want to go down that route to do so properly, as content negotiation is so simple, and there are an abundance of resources showing how to do it properly.
The goals of xhtml are never going to be realised by encouraging xhtml to be delivered as text/html. If you’ve decided that this issue isn’t important to you, then that’s fair enough. Sending out a message that this is acceptable, is both incorrect and irresponsible.
For clarification (yet again): I am not encouraging people to send XHTML content only as
text/html. I obviously think that if you can, you should send it asapplication/xhtml+xml.Then when you encounter a user agent that doesn’t accept
application/xhtml+xml, it is perfectly alright to send that UA an XHTML (astext/html) page. It is not incorrect as some people seem to believe – the specification states very plainly that you MAY send it as such. Even if I build an entire site as XHTML and decide to send it as text/html (this blog does just this!) there is nothing wrong with that, and it’s perfectly acceptable.This HTML vs. XHTML talk really makes me glad that I have other battles to fight. Jesus. Write HTML if you like. Write XHTML if you like. Send it however you want to send it. Either way, it’s not going to kill you and it’s not going to kill the web.
And for god’s sake, if you think application/xml is going to be a common way to send pages down anytime in the next five years, then encourage the transitional use of “imperfect” XHTML in the meantime. The more people who learn to write code this way right now, the easier it will be for you to achieve your grand XML vision.
If, however, you don’t believe in the XML holy grail, you can do one of two things:
1. INSIST on HTML over XHTML with the legitimate reasoning that it can save a tiny bit of bandwidth, makes vertically centering things easier, and a small handful of other advantages. Insist on it because of the advantages it provides *today* since this theory says that XHTML has no value, even in the future.
2. Concede the few bytes of bandwidth savings and other minor advantages and write XHTML anyway. Write it because you aren’t really sure if there is a future for XHTML (esp. served as application/xml) or not. This way, you have your bases covered.
I personally choose the last option.
Not if you’re sending it as text/html. You won’t notice the invalid tags, since it’ll be treated as HTML!
Given that sending as xml isn’t a possibility with IE’s handling of it, you can’t, so you must be encouraging it?!
The same as the drawbacks of sending XHTML? If you send something that doesn’t follow the standards, what should be done with it is “undefined”, and as such, it’s less likely that all user agents will do the same thing with it.
What is the advantage of sending XHTML as HTML? Absolutely nothing. You’re forcing the browser to do more work by sending invalid code. There’s only one way browsers are going to follow the standards and render code the same, and that’s if the code follows the standards. If developers don’t follow the standards, why should browser developers bother?
If the only advantage of sending XHTML is to “future-proof”, it won’t work. Sending XHTML as text/html is rendered differently and javascript is different, so when you do change over to sending xml mime types, you’ll find your site behaves differently. If you’ve got to fix it then, why not send HTML4 now, and change to XHTML when you’re ready to change the mime type?
Personally, I don’t think there’s enough support to justify using XHTML properly, but it’s catch 22. Browser developers won’t bother adding support if nobody’s pushing it. I think the best way is to store all your data as XHTML (such as marked-up articles in your database), and either do content-negotiation, or transform and send everything as HTML4. When things are ready to go XML, you’ve not got to edit all your articles (it’s easy to go from XML to HTML4, but not as easy to go the other way) and you can focus on the template and re-writing javascript/css to render correctly!
Actually Tommy never said it was harmful to send XHTML as
text/htmlagain he has been misunderstood; he was indicating it won’t act as an application of XML in that form.The reason he added that entry was because people were falsely accusing him of saying it was harmful.
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/htmlmeans that those beginners can make mistakes out of ignorance, such as enclosing style rules and scripts with SGML comments, usingdocument.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/htmlif you feel like it. It doesn’t hurt (much). You gain absolutely nothing, though.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 astext/htmlinstead 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+xmlthen it’s perfectly fine to send it astext/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.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…
Geoff, you are encouraging people to serve HTML. Serving anything as
text/htmlmeans that user agents must parse it as if it were HTML. That (and the fact that no browsers implementSHORTTAGScorrectly) 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/htmlif 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? :)
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 asapplication/xhtml+xmlif you can, but the minute you have to fall back totext/html, there is nothing wrong with sending those pages with an XHTML doctype.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.
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.
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…
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.
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.
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 <br> 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.
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.’
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.
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+xmlyou’ll notice these mistakes pretty fast via the ‘yellow screen of death.’ But if you have an entirelytext/htmlwebsite 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
embedtags, which I’m sure you are aware don’t exist in XHTML.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/htmlit 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.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.
Mike D:
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…
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.
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?
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.
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.
Adobe’s SVG plugin works only with SVG content included via the <object> 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 <p> element (for instance) is optional in HTML for a very simple reason: it is unambiguous that a <p> element ends when the parser encounters another block-level element or the close of the <p>’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 <p>).
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?
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.
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!”.