Graham Bancroft is not the only one really confused lately about whether XHTML or HTML is actually better/preferred/more correct/The Right Choice (that’s not to say that it’s a new debate). Ever since I had a chat with Anne about it a week or so ago, this issue has been playing on my mind more and more. I’ve invested some time in reading lots of articles and bits of specs in order to try to find out what the answer is but I’m still confused. The intention of this post is to have a balanced look at the advantages and disadvantages of each, in order to collect my thoughts and come to some sort of decision.
Start with an assumption
Serving XHTML with a MIME type of text/html is wrong. The whole point of XHTML is that it’s XML so that you can benefit from namespaces and the like. If you serve it as text/html, you can’t:
In particular, ‘text/html’ is NOT suitable for XHTML Family document types that adds elements and attributes from foreign namespaces, such as XHTML+MathML [XHTML+MathML].
You will also be serving your “XHTML” document as tag soup; it will be parsed as HTML:
XHTML documents served as ‘text/html’ will not be processed as XML [XML10], e.g. well-formedness errors may not be detected by user agents. Also be aware that HTML rules will be applied for DOM and style sheets (see C.11 and C13 of [XHTML1] respectively).
This is covered in greater detail in Ian Hickson’s excellent article, Sending XHTML as text/html Considered Harmful.
I can already hear someone shouting “backwards compatibility!” at me, so I will state that I do consider Content Negotiation an acceptable solution to the problem of Internet Explorer:
Authors who wish to support both XHTML and HTML user agents MAY utilize content negotiation by serving HTML documents as ‘text/html’ and XHTML documents as ‘application/xhtml+xml’.
So here’s the assumption. As it stands, at the moment, we, as web page authors, have two choices:
- XHTML 1.0 served as
application/xhtml+xmlto conforming UAs, andtext/htmlto Internet Explorer - HTML 4.01, served as
text/html(of course)
XHTML 1.1 is not an option because it mandates a MIME type of application/xhtml+xml which is incompatible with Internet Explorer (I’m assuming you want to support Internet Explorer; I certainly do).
XHTML
Let’s start by looking at the XHTML option. It has the advantages of:
- Mixed namespaces
- Much simpler to work with (for programs, at least) than HTML
- You will immediately know when your document is not well-formed due to an error from your UA. (Yes; I am assuming you use a real browser)
Notice how the first advantage doesn’t count because you are trying to maintain “HTML compatibility”.
Then there are some disadvantages:
- You are essentially maintaining two different documents: a HTML one, and an XML one; Javascript works a bit differently, CSS works a bit differently, etc.
- As Anne notes, there will not be incremental loading for Gecko browsers
Some further notes:
- I don’t consider parse errors a problem; well-formedness should be checked on the server-side
- XHTML 1 has no more/different semantics than HTML
HTML
Advantages of using HTML:
- None particularly
Disadvantages of using HTML:
- None particularly
Make a decision and go with it
I bet you’ve already guessed what my opinion is now. I believe the logical choice has got to be HTML. Not because it’s particularly amazing in any way, but because I feel there are no particular advantages or disadvantages of using it, whereas there are disadvantages of using XHTML (which outweigh the advantages). The one thing that would make XHTML 1 worthwhile is namespaces. But you can’t do that if you want to support Internet Explorer. I don’t need to do that anyway.
My redesign will be done with HTML, served as HTML, validating as HTML.
Anne has seen quite a lot of hosility due to his opinions on this subject, so I ask that you respect my decision here; I certainly respect yours.
Right now I feel like an aetheist who set out to prove Christianity wrong, only to end up believing in it (actually it’s nearer the other way around for me; I used to be Christian). I always thought that XHTML was the Right Thing to use. Hell, I didn’t even know what I thought when I started writing this article. If you are unsure yourself, I strongly urge you to investigate. Read the specs, read what people are saying on the subject, and if you can’t justify using whatever combination of markup and MIME you currently use, something is up.
I don’t consider XHTML to be useless
Not by a long way. If you want to mix namespaces (and in doing so, sacrifice IE support), then it is useful now. The forthcoming XHTML 2.0 also looks very promising, although in order to use it we’ll need support from IE—I sincerely hope that Microsoft make that one of their bug fixes for IE 7.
(Yes, I know XHTML 2.0 isn’t backwards compatible. The web needs to keep moving forward. One day (in the very distant future), non-conforming UAs will be a minority, and we will need to sacrifice backwards compatibility. I think that’s acceptable.)
When you feel frustrated about this all…
Remember that you are writing semantic markup. Remember that you are applying your page presentation with CSS. Remember that you give a damn about accessibility. Remember that your websites are better than 99% of the crap out there—whether you decide to use XHTML or HTML.
(You are aren’t you?)
Acknowledgements
Thanks to:
In the end, it’s easier and more logical to go with HTML. It’s also a bit of a cop-out. HTML’s (or rather SGML’s) obscene lenience in approach has been the cause of tag soup pages in the first place. Sure, it’s possible to write non-tagsoup HTML, but therein lies a great danger that has been reiterated time and again by many people: new, young developers will not know the finer details and are likely to end up with incomplete pages and serving them as XHTML because it’s still “the hot thing to do these days” (not to mention that all the A-list people still create everything in XHTML).
On an unrelated side note, your larger headings are completely illegible; no lineheight, cut-off texts, no letter spacing… okay, I can
somewhatread them, but only with difficulty. Is this..intended?Additionally, your forms are lacking a color: specification. I’m writing this in light gray text on a white background—very hard to do! :(
Faruk Ateş
Tuesday 31 May
11:46 AM
I would be lying to say I understand more than a few words of this, authough I have read it all the way through …
but …
Are you saying that after lecturing me how XHTML was better you may be wrong about something geek related?! Wow ;)
I hope you find answers to your big questions, most of the world have big crises about their sexuality or religion – and you are pondering on the correct programming language.
You rock. Ha
esther
Tuesday 31 May
11:09 AM
Faruk, thanks for your comments. You are, of course, absolutely correct about new developers getting the wrong idea. But I don’t feel we should make markup choices based on new developers’ assumptions. Furthermore, if I had Content Negotiation, I wouldn’t want a new developer to see me using
application/xhtml+xml, and think it’s okay to use, or the other way round, to see me usingtext/htmland think that’s alright (which would of course depend on what browser they are using). Being server-side, they wouldn’t know about the Content Negotiation.I will write good, semantic, structured HTML, and I hope that those really committed to learning web development will have the sense to do some investigation rather than just copy my code. Those who do will most likely be successful, and those who don’t most likely won’t. But there will always be people making crappy websites. Nothing we can do about that. Still, I will put a comment in my source code with a link to this post, so that people viewing it have the opportunity to become aware of the issues.
Sorry to hear that you are having some rendering problems with my site… I’m not sure what’s up though; I haven’t had anyone else report anything like that. Could I ask you to email me a screenshot please? (turnip at this domain) Do you have any user style sheets/scripts that might be interferring? What browser are you using?
Esther, thanks for your comment too ; ). I wouldn’t say I was wrong because I do think XHTML is better… but it just isn’t appropriate to use right now because using it in the correct way would mean either maintaining essentially two documents, or sacrificing support for Internet Explorer. Not that you care… ; ). I certainly do have a better understanding of markup language now than when I first came across XHTML.
Turnip
Tuesday 31 May
12:03 PM
Well, I make the markup choice myself based on my experience and personal preference. I’ve had to train interns to write semantic code and everything, and the XML-based approach is a much more powerful one for this purpose. It’s been much easier for me to teach them about semantics and all the finer details after having first taught them to write well-formed, complete code.
Also, thanks to XHTML, our javascript wizard has become a skillful DOM-scripting wizard, not ever using techniques that would only work in HTML. I rather like that, as (to me) DOM-scripting is much better than using document.write() and innerHTML…
Faruk Ateş
Tuesday 31 May
01:10 PM
Faruk: strange. I have seen you arguing that not allowing document.write() in XML was nonsense. At that time I was actually giving you arguments for not allowing it and you didn’t quite buy it.
Anne
Tuesday 31 May
11:26 PM
I’m serving XHTML 1.1 to UAs that accept it, and HTML 4.01 strict to the rest. It validates for both (the markup is subtly different between the two, of course), and wasn’t difficult.
However, I’m an edge case. I’m doing this because I can, and I have no real idea how long it’ll last. Probably not very. Everybody sensible should just pick one and get on with it. XHTML does have distinct advantages over HTML in terms of ease of processing, if that’s how you get your content out of the door. Other than that, though, I think it’s pretty much a matter of preference.
Personally, I’m more concerned about the the sheer amount of badly-formed invalid markup out there than the choice between HTML and XHTML. Call me old-fashioned.
Oh, and your live preview thing is cool!
Mo
Tuesday 31 May
11:11 PM
I pretty much agree with all that is written in this post, except one:
I think it’s better to use XHTML (with all the MIME mumbo jumbo) even when you are not combining it with any markup from another namespace. Right now you may not need it, but it is pretty likely that at some point in the near future you will. I for one am glad I have been using XHTML pretty much from the start of my website, so that I didn’t need to convert my entire website to it just to add an SVG pie chart to the user agent statistics (in which case I probably just wouldn’t have bothered).
IE support is becoming less and less important every day :). Besides, it is not unprecedented to only offer certain content or functionality to browsers which support certain features; if they want to see it, they should use/upgrade to better tools. Especially when that content is more or less redundant, or not really very important, and the main content is still understood by the UA when received as text/html. But also in other cases when the technologies XML offers are just really the best solution. MathML for example is really the best way to represent math on the web – images are a very suboptimal solution. Vector graphics can also be drawn to images, however that is really only a solution when they are static.
If you create your site as XHTML from the start, it isn’t hard. Some scripts might not work – ah well, you rewrite them, find XHTML equivalents (although I wouldn’t know where either :), my website has a few), or just don’t use them. But that’s basically the biggest issue. That will save you much trouble later on, because if you have to convert an entire existing site, including pages and pages of content and scripts and whatnot – that can be a pretty big effort. And given that I think it is pretty obvious to see that in the end the web will move to XML, be it in 2, 5 or 10 years… Why not save yourself the effort.
So, the sooner you start, the less trouble it will be for you later on :).
~Grauw
Laurens Holst
Wednesday 01 June
12:41 AM
Oh, p.s. mo: that live preview thing would be one example of a script which would be pretty hard to create on an XHTML page :). When you want it in the exact same form, at least. If you just show a big invalid comment note (and also disable the submit button while you’re at it) whenever the script gets a parsing error because the comment is not well-formed, it would actually be a nice way to give people both a preview of their comment, and immediate feedback as to whether their markup is ok (as opposed to only after submission).
Laurens Holst
Wednesday 01 June
12:47 AM
- You can view XHTML with a mobile phone, especially when using strict markup and a stylesheet for media:handheld. - HTML is not being developed further by the W3C; it’s a dying language without a future in the long-run (although almost nobody knows) - XHTML is the end of transitional markup since XHTML 1.1 only allows strict markup - XHTML is the current standard for hypertext documents
Mega
Wednesday 01 June
12:18 AM
p.s.2. with regard to the lack of incremental loading – actually I had a bug in my referrer log statistics report page, where the number of results was cut off at a certain limit. The page ended up (causing my server bandwidth for this month to be a whopping 900 MB because search engines felt the need to hit the page like 1500 times). Amusingly enough, I didn’t really notice the load time at first. But then again, I was looking at it while I was at my university _.
Seriously though, a semantically marked up XHTML document, especially when gzip compressed, is usually only a fraction of the entire load time of a web page (unless you are serving W3C specs :)). Pretty much the biggest page of my website, the index, is still only 4.63k (about 12k uncompressed). In a documentation site I run, a 35-page manual is 22,75k, which also loads in a blink. So I don’t really consider that an issue.
~Grauw
Laurens Holst
Wednesday 01 June
12:38 AM
Laurens, you’re right, of course. Having a website that’s already working properly as X(HT)ML will make things easier in the future. However, it comes with the price of maintaining two documents, which is inpractical (in my opinion)
- stuff like that always seems like a good idea, until you actually try to do it and find out the problems the hard way. I’m not saying it’s impossible, but just more effort than it’s worth. The fact is, HTML works now, consistently, and will continue to do so for the forseeable future. XHTML doesn’t. I would perhaps be more leniant towards XHTML if I didn’t consider it pretty easy to switch to it when the time comes -but by virtue of the fact that all my posts are in a database, I don’t think it will be a huge problem. Furthermore, future-proofing is a idealistic pipe dream. Furthermore, XHTML 2 is backwards incompatible, and I don’t know how likely it is that I’ll be able to switch to XHTML before version 2 is ready and available for use.Your comment on IE is slightly strange. The need to support IE is the reason I won’t use XHTML. I don’t see that need changing any time soon. If I was happy to drop IE support, I’d just serve straight XHTML 1.1 as
application/xhtml+xmlwithout any of that Content Negotiation crap (well, actually I’d serve up a Get a real browser page to IE).I know this isn’t the point, but SVG can be served with the
objectelement. I have no need for MathML in this website. I guess it’s important to assess the needs and desires of a particlar website when making The Markup Decision. I have done so for this website and ended up with HTML. (On a side note, your pie chart rocks!)Turnip
Wednesday 01 June
12:58 AM
__
(the cloud is smiling!)
With regard to IE, I’m fine with serving visitors using IE something legible, but no more than that. I can’t bring myself to bother… My website is there to do things I like, not to work around IE bugs or let it limit me in the things I want to do (well, I do care about IE, but only to a certain extent). That’s kind of my philosophy :).
But even on broader-scale websites, I think there is something to be said for the notion of ‘progressive enhancement’. Be it on a small scale such as styling rounded corners with border-radius, or on a larger scale with e.g. an SVG image where appliccable or whatever other XML technology there is or will be. Worst case the visitor will miss a tiny little bit of content, best case he gets curious and actually upgrades to a better browser :).
And why not? The web has survived, thrived, for years during the time when browsers were still new and new features which were often backwards incompatible were added to (and used on) the web each month. Why would that have been possible then, but not anymore now? It’s kind of like the
<canvas>element the WHATWG is adding to (X)HTML. It won’t work in IE (or at least, I do not expect it will, in IE7). But at least we now have the advantage that it is 1. standardized, and 2. well-thought out with a clear specification and fallback mechanism. But if we wait ‘till eternity for IE to support it before using it on our websites, we’re just at a standstill. Use it! Tell people they’re actually missing out on something!~Grauw
p.s. Something just popped right into my mind. It’s brilliant: Firefox as an ActiveX plugin! Well? Well? :)
Laurens Holst
Wednesday 01 June
02:36 AM
[...]
davidbisset.com &raquo; “XHTML or HTML?â€
Wednesday 01 June
03:07 AM
Laurens, you’ve posted too many comments—your last one got a -15 from Spam Karma! ; )
I still don’t agree about the lack-of-support-for-IE issue when it’s perfectly easy for me to support IE without compromising any features in the process. And I certainly wouldn’t agree if it was for a client. But anyway…
Your Firefox ActiveX plugin is genious! File a bug! One thing though, make sure that the Mozilla folks work closely with spyware manufacturers so that we can make sure the users don’t have to go through a tedious install process. We wouldn’t want that… ; )
Turnip
Wednesday 01 June
10:07 AM
That little “XHTML or HTML?” debate
An excellent entry on the “hard” decision between choosing HTML and XHTML by Jonathan Leighton. As you probably know, I went back to HTML not so long ago.
misinterpreted.org
Wednesday 01 June
01:32 PM
’ ‘
Anne, I can’t for the life of me remember anything like that, and I highly doubt it. There’s a difference between finding something nonsense and trying to come up with a case for something to see if it has any value. Clearly I’ve found no value, or else I wouldn’t be so thoroughly against it…
Faruk Ateş
Wednesday 01 June
02:59 PM
I choose XHTML because the HTML MIME is unsemantically pedantic when compared with next-generation solutions like SGML. Furthermore, Internet Explorer sucks.
(Editor note: I told Alice to make a profound comment on this topic, and she didn’t know what to put, so I made it up for her… please don’t flame ; )
alice
Wednesday 01 June
02:59 PM
Hmm i believe this debate has been around for err ever? Well atleast since XHTML came to life. I personally believe it’s prefrence. But more and more of the designers are using XHTML…. XHTML does require more work.. well hmm no it doesn’t :S Bah i don’t care i’m going to continue to use XHTML, as i said personal opnion
Dave
Wednesday 01 June
02:43 PM
<img>tag (or even an<embed>one, which works in IE but is a little counter-intuitive to me). But, that’s half the fun, and I would have to copy the statistics logic to a separate script for the image… I don’t really like introducing redundancy.As for doing that for a client, it depends on their audience, and to what degree the unavailable feature gives added value (and to what degree IE users will miss it). But yeah, I basically agree. Nevertheless, personal blogs and information websites aren’t commercial companies which can’t afford to not fully support IE, so especially when they have a technical audience I’d say: sure, why not!
Most certainly not! ^_ The bug is here.~Grauw
Laurens Holst
Wednesday 01 June
03:25 PM
Joe Grossberg
Wednesday 01 June
04:17 PM
Joe, I don’t know if it’s possible using a .htaccess file—it’d certainly be hard. The best way is to use a server side programming language. Mathias wrote some code to do it, and talks about that in his post, XHTML Content Negotiation through PHP. I’ve heard it’s pretty good, but then again, it was Mathias who told me it’s pretty good ; ).
Turnip
Wednesday 01 June
05:01 PM
Joe:
RewriteEngine on RewriteBase / RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0 RewriteCond %{REQUEST_URI} \.html$ RewriteCond %{THE_REQUEST} HTTP/1\.1 RewriteRule .* - [T=application/xhtml+xml]Henrik Lied
Wednesday 01 June
11:53 PM
I stand corrected : ).
Turnip
Wednesday 01 June
11:48 PM
[...] During the discussion following my [...]
Turnip&#8217;s Patch &raquo; GeckoX
Thursday 02 June
11:19 AM
I was looking for that recently as well (to make the odd one or two .xhtml files do something in IE as well). But the problem with that particular .htaccess is that you have to match on file extension, and can’t match on MIME type. I would rather have said something like ‘for all application/xhtml+xml files’, so that it would also automagically work for other files with the same MIME type.
So it isn’t the cleanest solution, but then again, if it works… heh :). Isn’t like you’re going to MIME any files other than .xhtml and/or .html.
~Grauw
Laurens Holst
Thursday 02 June
04:32 PM
Sorry for replying so late, Jon. I already read this article the day you posted it. I just didn’t want to write a comment that’s too short to express my exact thoughts. Anyway, now that I got some spare time, here goes!
That last part is particularly interesting. I’m afraid I don’t quite understand it though. How can XHTML 1.0 be a choice, whilst XHTML 1.1 is out of consideration? Did you just mean XHTML, or what? If not, I just wanted to let you know that I’ve been writing my site is XHTML 1.1 for ages, and, surprisingly, last time I checked, everything seemed to work quite well in Internet Explorer. (Quite well, yeah right. You get my point though.)
Another thing I don’t seem to get. If you really don’t need to do that, why not just say ride the punanni yous to IE and use XHTML anyway?
I’m not evangelizing XHTML here, I just wanted to throw in some additional arguments (i.e. my thoughts).
Mathias Bynens
Thursday 02 June
05:11 PM
Mathias, with
XHTMLXHTML 1.1,text/htmlis a SHOULD NOT, andapplication/xhtml+xmlis a SHOULD (reference). Thus, you wouldn’t be able to both conform to the spec and serve it to Internet Explorer.Because that would still mean serving up two different documents. So what would be the advantage? HTML works—without namespaces there are no significant advantages of using XHTML over HTML.
Turnip
Thursday 02 June
05:42 PM
I know. It’s just that I was (I still am, in fact) confused about the XHTML 1.0 vs. 1.1 thing. Perhaps it’s just me, but you made it look as if XHTML 1.0 is an option, but XHTML 1.1 not…
Say what? I was talking about serving up your XHTML as
application/xhtml+xmlat all times. (Because you don’t need to support Internet Explorer anyway…)Mathias Bynens
Thursday 02 June
06:23 PM
XHTML 1.0 may be served
text/html, provided it fulfills the requirements of Appendix C of the XHTML 1.0 specification. Since it’s a mere reformulation of HTML as an application of XML, it contains exactly the same things as HTML 4.01 (with the corresponding DTD).XHTML 1.1, however, is not fully compatible with HTML, since it doesn’t include the
langattribute (it’s been deprecated in favour ofxml:lang). Thus you should not try to serve it astext/html.Besides, anything served as
text/htmlis HTML, regardless of the doctype declaration and any XML namespaces.Tommy Olsson
Thursday 02 June
07:06 PM
Ooops… okay, I fucked that last comment up. When I said XHTML, I meant to say XHTML 1.1. Sorry! So the 1.0 vs. 1.1 thing, as you put it, is that
text/htmlis a MAY in 1.0, whereas it’s a SHOULD NOT with 1.1.With regard to my comment about serving two different documents, what I mean by that, is when you’re using a
text/htmlMIME, you’re serving a HTML document, whereas if you use aapplication/xhtml+xmlMIME then you are serving an XHTML document. Thus, two different documents. And they are too different documents, because they will be rendered, complete with Javascript and CSS differences, based on the MIME, not the DOCTYPE declaration.Which is basically what Tommy said, but hey ; )
Turnip
Thursday 02 June
08:48 PM
Henrik Lied, you are a stud.
Joe Grossberg
Thursday 02 June
08:35 PM
XHTML Vs HTML
Turnip’s Patch has en excellent writeup on the debate (He ends up pitching for HTML!),
“Graham Bancroft is not the only one really confused lately about whether XHTML or HTML is actually better…
Pagevie.ws
Friday 03 June
03:43 AM
Tommy, tiny but important correction:
...is treated as HTML, not is. I can serve my GIF images as
text/htmlif I were so inclined, but that doesn’t make them HTML. Applications will treat them as HTML, but that’s a big different.Faruk Ateş
Friday 03 June
10:01 AM
This cloud is annoying
I would say that both HTML and XHTML are good options, but XHTML isn’t really necessary, and I’ve started to use HTML instead of XHTML on my new projects, simply because XHTML would be more work, with content negotiation and all, and I can’t really use the advantages of XHTML nor do I need them yet. Still, I consider myself pretty forward compatible by creating well formed tags in HTML.
But even how fare into the future, it will always be a question of backward compatibility, so what I’m looking forward for is a server-side XHTML -> HTML converter(not server-side XSLT cause it keeps the xhtml namespace) so that you can create truly accessible sites.
taare
Friday 03 June
08:25 PM
I make xhtml 1.0 Strict doctype pages and still just serve them as text / html. I really don’t see how it’s harming anything… please explain. Did I hurt you? Did you lose a shoelace? Sorry but it seems like a very tired argument by now. If my xhtml served as html is still html then is html breaking the web? So what it’s well formed markup…
The fact is that it at least validates to a strict doctype irrelevant of the MIME type. Evangalising HTML vs XHTML from either end is a bit of a waste of energy really.
Compare my code to the shite flopping out of DreamWeaver and FrontPage lol. God forbid I’d break the web.
But to each his own I guess and please nobody hate mail me over this one lol. I create xhtml pages as I’m slowly learning and transitioning forward myself. When I’m more comfortable I’ll move to delivering as xml perhaps. There’s a big assumption that we’re all old hat and know the specs by heart. I’m like most people – I make my pages to the best of my current ability…
I don’t consider that to be either bad or unprofessional. I still would like to know what part of what is breaking because I do this ungodly practise of delivering as html… by doing so i sit next to you. Well formed markup must be a good thing, must it not.
Or have I missed the whole point of this? Why is it the end of the world for some people lol… is funny :)
nortypig
Saturday 04 June
06:32 AM
[...] r: (X)HTML — 6:53 pm Is it really about HTML vs XHTML or about Web evangalism? So what if I’m coding pages up as XHTML 1 [...]
&raquo; Isn&#8217;t HTML vs XHTML Dead Yet : Pig Work : Weblog of Freelance Designer
Saturday 04 June
08:00 AM
SHOULD NOT does not equal MUST NOT. Therefore you are not non-conformant if you do not send it as application/xhtml+xml. There is a very strict difference between the two, had the HTML WG intended it a strict requirement then they would have written MUST.
Interpreting it any differently is just wrong, simple as that.
Look, I am doing it right here. Shame on me. Now the world will end ;p.
Laurens Holst
Saturday 04 June
10:02 AM
<output method="html">. It outputs<br/>as<br>, etc, pretty much just generates an HTML document, as you would expect.Laurens Holst
Saturday 04 June
10:08 AM
[...] views Jonathan Linczak Javascript: what’s next? Who Cares about Semantics Anyway? That little "XHTML or HTML?" debate Dr. Strangeswitcher or: How I Learned t [...]
torresburriel.com &raquo; Lecturas sobre hojas de estilo y estándares web - 04/06/05
Saturday 04 June
11:35 AM
I have to agree with nortypig. How can using valid XHTML 1.0 served as text/html harm? What problem can this cause? After reading through this and the related articles, I can’t see any problem with this. Allthough this is not a complete XHTML solution, it is a step in the right direction. I belive that is better than not taking that step at all. Why should XHTML 2.0 solve anything? Most likely XHTML 2.0 will result in the same effect as XHTML 1.1 has had. A lot of people will use it the wrong way, and the thought of everyone adapting and all browsers supporting is unrealistic.
My advice is simple. Make an attempt to validate and check the result of your markup in as many browsers as possible. The mime-type you are using is really not an issue, as long as it works. The world will never be perfect, and neither will the web be.
Bza
Saturday 04 June
11:20 AM
I use:-
if(stristr($_SERVER[“HTTP_ACCEPT”],”application/xhtml+xml”)){ header(“Content-Type: application/xhtml+xml; charset=iso-8859-1”); echo(’’); } else { header(“Content-Type: text/html; charset=iso-8859-1”); echo (’’); }
What is wrong with this, It serves up to IE XHTML 1.0 with text/html but the real stuff to the real browsers. This means you only have to use XHTML make sure you dont use the lang atribute and only xml:lang and you will be fine and it will validate.
Schultzy
Saturday 04 June
11:04 AM
[...]
Crap
It missed out the doctypes it should be
if(stristr($_SERVER[“HTTP_ACCEPT”],”application/xhtml+xml”)){ header(“Content-Type: application/xhtml+xml; charset=iso-8859-1”); echo(’<!DOCTYPE html PUBLIC ”-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>’); } else { header(“Content-Type: text/html; charset=iso-8859-1”); echo (’<!DOCTYPE html PUBLIC ”-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>’); }
Schultzy
Saturday 04 June
11:16 AM
nortypig, no, it doesn’t harm me in the slightest that you are serving your documents as
text/html. Notice how I did not approach the article from the point of view of other people harming me, but rather I was trying to take an objective look at the pros and cons of each, and sharing it with my readership in the hope that it might be helpful or interesting to other people.Rather than approaching it from a perspective or what’s wrong with serving XHTML as
text/html, it would be perhaps better to ask yourself what the advantages are? Why do you need XHTML, and opposed to HTML? Furthermore, if you are willing to follow the W3C recommendation of writing your documents in XHTML, then why are you not willing to take their recommendation of ”’application/xhtml+xml’ SHOULD be used for serving XHTML documents to XHTML user agents”? (That’s rhetorical; just think about it.)Perhaps you should re-read what I said under the heading of “When you feel frustrated about this all…”
Laurens,
Thanks for that information. You’re absolutely correct, however, people tell me a shouldn’t smoke, and give me reasons for it, so I make that decision not to do so. In the same way, just because it wouldn’t strictly be a violation of the spec to serve XHTML 1.1 as
text/html, that doesn’t make it a good idea. Still, I maintain my stance that everybody needs to make their own educated decision on such issues.taare,
As Laurens pointed out, this is possible with XSLT, however, tell me, what’s the difference between doing that, and using the two different MIME types, in terms of maintenance?
Schultzy, nothing’s wrong with that—I said so in my article:
Turnip
Saturday 04 June
03:24 PM
Ha, look at my cool ordered list with speech bubble numbering ; ).
Turnip
Saturday 04 June
03:16 PM
No mine serves up XHTML 1.1 as application/xhtml+xml to conforming UAs, and XHTML 1.0 as text/html to Internet Explorer. Making it up with the future as possible.
Perhaps we should all write XHTML 2.0 even though it isnt out.
Schultzy
Sunday 05 June
11:55 AM
Oh right, yeah (sorry—didn’t look closely enough). There’s nothing fundamentally wrong with that, other than it creates even more work for you because 1.0 is meant to be HTML compatible whereas 1.1 isn’t.
Turnip
Sunday 05 June
11:47 AM
Well I just have them as the same it validates as both.
Schultzy
Sunday 05 June
11:12 AM
Jonathan, sorry for being late to the party. I do think it’s good to write these kind of posts, to raise the question and to point to the disadvantages and advantages of either way.
Of course people will never agree totally on this, nor find a common ground on how everyone should do, and that is the way it should be. I totally agree with what you wrote, that people need to make their own educated decision based on the facts you (and the people you link to) mention in their posts.
In the end, I think that being semantically correct and tending to accessibility factors while writing valid strict HTML or XHTML are the most important things.
Robert Nyman
Sunday 05 June
05:33 PM
Turnip: Let’s put it this way – why shouldn’t I write XHTML 1.0 Strict and still deliver it as text/html at this point? If I wrote it in HTML then it’d be a lot harder when I decide oneday to actually deliver it as xml, or if I decide to use XSLT in the future (which I may play with). But everything is evolutionary – time to do this, the growing skills base to take the next step, the flexibility to incorporate it into paid jobs as well. So for the time being I am like the diver on the platform – at least I’m up there. If I’d written in HTML I may well have to recode sites to take that next step. So as a business policy I have that as my official line. I’m more concerned with accessibility, cross browser compatibility and usability.
It’s a policy I’ve made as a balanced educated business decision. I’d fail my clients by offering them less than I could realistically achieve for them. There’s nothing wrong with HTML Strict either, for that matter. Not yet anyway. But eventually there will be and as IT professionals we know that nothing will stay the same. HTML has had it’s last version and eventually XHTML will and we’ll be onto an XML web. That’s life I guess.
I suggest as long as the evolutionary approach is being taken there can’t be too much that I’m really doing wrong. Of course, time poor, I can’t be a master at all things and can only do my best for any given time and client. It’s not the end of the world for anyone either lol.
nortypig
Tuesday 07 June
06:35 AM
nortypig, you “put it that way” in your previous comment, and I answered you in my previous comment. Serving XHTML as
text/htmlgoes against the assumptions that I very clearly stated right at the begnning of the article. And I gave reason for them. If you don’t agree with that then fine, but asking me why you shouldn’t do it seems a bit silly given that I’ve already explained why.Turnip
Tuesday 07 June
08:17 AM
Bza
Tuesday 07 June
09:27 AM
No, I assume it’s wrong if the User Agent supports
application/xhtml+xml. You quoted me out of context.No they don’t. I’ll quote them word-for-word:
That’s just your opinion. In my opinion, I am accepting that the web is not yet ready for the proper use of XHTML, and I am also accepting that I have no need to use XHTML. If and when the time comes that I can use XHTML properly (and I’m sure it will do), I will start serving XHTML. All my content is stored as well-formed markup in the database, and that’s not going to change (I will just convert <br /> to <br> with a WordPress filter), so when I do come to switch to XHTML, it will just be a matter of changing the markup in the template. Like you’d change the markup if you were, say… redesigning a site.
As I said in the article, forward compatibility is a myth. Nobody in their right mind thinks they can create a site that will work perfectly on the browsers of 5 year’s time. Yes, that’s the idea of standards but every single browser out there does have and will have rendering bugs. Particularly IE.
Turnip
Tuesday 07 June
10:54 AM
Tom
Tuesday 07 June
06:13 PM
I do see advantages of XHTML 1.1 though. For example, the XHTML + MathML Doctype is using XHTML 1.1 (because of the modularization), and as I once posted something with MathML on my blog, and have expressed a formula with it on another site, they should be XHTML 1.1 (actually, I was using XHTML 1.0 previously, but since I made the MathML post changed it to 1.1). I’m also looking forward to being able to use Ruby. And at work we use XHTML mixed with our own BXML tags, for which I am working on generating a Schema, and for that I need XHTML 1.1 as well.
So from all those things, I see that XHTML 1.1 is better than 1.0, and I would let a tiny recommendation from the spec authors which is in no way a requirement stop me from using it? No way! :)
Besides, I like to use ‘the latest thing’. And if it works, why not?
~Grauw
Laurens Holst
Wednesday 08 June
02:48 PM
Two more things:Future-proofing by itself may be not really realistic as by then things will probably have changed again, but using HTML 4 is quite the opposite :). If you have the opportunity to use XHTML, why not use it.I find XHTML or XML in general to be structured much more logically than HTML is. I think that it will also be easier to explain to newbies, because it is consistent and there is no such thing as ‘but for these tags you can leave out the end tag, because saving four bytes on a
</p>is pretty worthwhile, and you can just guess about where the paragraph ends then’ and ‘oh, and in the DOM they are uppercase, even though you used lowercase’ and all that kind of crap. I still remember having difficulty with that when learning HTML, and in the end just always using</p>because at least that made sense.~Grauwp.s. your unordered list looked terrible in the comment preview, which is why I used an ordered one even though there is no particular order in those arguments :).Laurens Holst
Wednesday 08 June
02:23 PM
[...] s XHTML Dead Yet which is a comment on the latest flame in the standards arguments over at Turnip’s Patch. The question is usually what’s the benefit of using HTML [...]
&raquo; HTML vs XHTML Questions : Pig Work : Weblog of Freelance Designer Steven Clark aka N
Saturday 11 June
12:27 AM
XHTML, HTML and the What Challenge?
In the interview “Ten questions for Russ Weakley,” Weakly talked a bit about the “MIME type challenge” and gave references to a number of articles on the subject. As you may already know, I’m sometimes a little slow on the uptake. This is the fi…
KathyMarks.com
Friday 08 July
11:43 PM
HTML vs XHTML: The Redesign Battle
As I'm working on the redesign for my site Adam and I decided that it should use HTML 4.01 Strict rather than XHTML. Basically it boils down to the fact that in order to actually use XHTML correctly you have to completely sacrifice Internet Explor…
BryanSchwegler.com
Sunday 10 July
03:23 PM
[...] There are several other flavors of the same debate going on: Valid vs. Invalid RSS and HTML vs. XHTML. In both of these cases, there are the theoretically pure on one side of the debate, and the in the trenches pragmatists on the other side. [...]
Adam Platti&#8217;s Blog &raquo; Blog Archive &raquo; Sometimes You Should B
Monday 07 August
09:28 PM
I switched to XHTML, and then switched back. But I still write XHTML and then sort the DOCTYPE out (and tags such as br and img) dynamically using php. So my documents valid are xhtml (I serve the correct mime type to the W3C validator to check it properly), but browsers get valid html. I’ve written about this an posted the php code (click my name link if you want it). It’ll be easy to swtich back to valid xhtml 1.0 strict if I ever need to!
Dave Higgins
Monday 18 September
01:36 PM
I’m a latecomer to this debate, and I see there was lots of activity a couple years ago on this issue, but see almost no mention of it in the past year. Do people still feel the same way? I understand the rationale, but at the same time it feels weird to go “backwards” to HTML 4.01.
Ryan Sandridge
Saturday 30 June
04:08 PM