XHTML is a joke
Posted on 1/5/08 by Felix Geisendörfer
Hey folks,
I don't know how often I had to discuss this with people over the past months, so let me say this once and for all:
XHTML is a joke. It is an elitist trend against the very nature of the web and offers no advantages over HTML 4.01 strict!
This is an old old discussion and there are great resources that list all of the problems associated with using XHTML. All I want to address in this post are two problems I have with XHTML:
1) Strict rendering is a STUPID idea
I don't know if I am the only one that realizes this. But if all your favourite web sites were to be converted to XHTML strict most of them would be unusable half of the time because of tiny errors in views. XHTML promotes that the slightest mistake in your markup will cause your page to NOT RENDER!
To me this is the most ridiculous concept ever. The view / presentation is the least important layer in any application and XHTML says it should be able to completely crash your page. Give me a break, but this is madness.
[Edit: 2008-05-02] When I say that the view is the least important layer than I mean that it should be most the forgiving layer because it does no business critical data processing.
Publishing content on the web should be easy for everybody. I am against anything raising the bar in that regard. Of course I wish MySpace never happened, but millions of people absolutely love the idea of expressing themselves in the most ridiculous ways. Heck, if I never had gotten into the web industry you can bet that I would have a 5mb MySpace page that brings any browser to its knees.
So let us come up with better standards, but please make them forgiving about mistakes within reasonable boundaries. The main reason we all use PHP (or any other dynamically typed language) is that we hate strict boundaries. We love flexibility in any form, and I strongly believe that flexible and forgiving standards are far superior in terms of enabling innovation compared to strict standards like XHTML.
2) Presentation agnostic XHTML is an ILLUSION
The biggest advantage people see in XHTML is that it is supposedly better at separating content from presentation. That is BS. XHTML pretty much supports the same set elements as HTML, including strictly presentational ones. But more importantly: If you ever tried to completely change the design of an XHTML page I know that you cheated and changed the markup.
[Edit: 2008-05-02] The above is meant in the context of real world situations with dynamic content. CSS Zen Garden and similar sites are not realistic web environments. See comment below.
So if you are under the impression that by using XHTML your pages automatically become presentation agnostic data sources that can be aggregated you are hallucinating. Microformats and web scraping is what you should look into.
Conclusion: I think XHTML did a ton of good for the web. It gave people a way to draw a line between traditional table driven HTML layouts and modern XHTML / CSS approaches. It spawned a wave of support for semantic markup and web standards. But looking at XHTML as a format by itself I see no advantages in it. I have big hopes for HTML5. Meanwhile I feel very happy with the feature set and philosophy provided by HTML 4.01 and will continue to use it.
Looking forward to feedback on this.
-- Felix Geisendörfer aka the_undefined
Did you like this blog post? If so, please consider subscribing to the Blog RSS feed.
You can skip to the end and add a comment.
From a user's point of view, the presentation is pretty much everything for a web application and as such it needs to be "correct" across all browsers. I believe the idea is that XHTML will help get us towards that goal where we can write once and have it understood by every browser.
I agree somewhat with the "One mistake ruins an entire page" issue, but in the end it's really in everyone's best interests to set those goals and stick with them. Think of it as sanitizing your output.
Felix,
There are many reasons not to choose XHTML, and go with HTML, but your assertion that "the slightest mistake in your markup will cause your page to NOT RENDER!" has *nothing* to do with whether you choose a Strict or Transitional DocType. It's to do with the mime-type that the document is sent as.
If you send your XHTML as application/xhtml+xml (to browsers that support it, sniffed using the http_accept header) *and* your markup goes screwy, then - yes - the entire page will fail. This, however, would happen in XHTML Transitional as well as Strict.
Joe: Yes, I guess I phrased that poorly. The view is so important that no trivial error in its markup should cause it to be completely inaccessible.
Tim: I'm not talking about Transitional, I talk about XHTML strict. If you use a transitional doctype you might as well use HTML 4.01 since you admit to not adhere to the full standard anyway. If you serve XHTML with the wrong mime type it gets parsed at HTML not XHTML, so whats the point of even discussing this obvious stupid way of doing things : ).
At least you don't have a strong opinion on it. ;-)
I'm a fan of microformats, I see them providing more and more power as they spread.
Thanks for the article. I was beginning to think I was the only one who felt this way. Long live "<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">"!
"this obvious stupid way of doing things"
Welcome to the real world. It wasn't "obvious" in what you said, which on the face of it was flat out wrong.
XHTML should be send as application/xhtml+xml, to be real XHTML. But since IE doesn't support that, 99% of all websites running XHTML are sent just like regular text/html. Which means it is indeed bullshit to use the XHTML doctype if you send the page as text/html..
xhtml would only be worth it if it actually did something special for you, or got you magically better rankings. it doesn't.
try running a large site with strict xhtml where you allow ads, or have a CMS that people not so html savvy get to input content.
how long before your site no longer validates, or just breaks because of some silly error.
which brings me to the whole XTHML Validated banners people run on their sites. what's the point? validation gets you NOTHING other then some technical kudos. it does not get you better rankings, does not make your site perform any better*, and it doesn't increase your sex appeal. i stopped trying to validate once i realize that so many projects ive done once they leave my computer get mangled. whats the point in spending extra time, unless its billable.
now i do use the validator or htmlTidy when a page is acting weird. It is great at finding bugs or open tags etc. i sleep better at night not worrying about page validation.
* sure some sites have really terrible html, and yes a site that "validates" would probably perform faster, but i think we are talking about A level sites, not geocity pages.
Every standard has stupid sides it's normal. But, I don't think that xhtml is useless. It has lots of features. Lots of places you can make incredible things.
I totally second kenrick. Though I still sometimes validate markup just for the sake of it. Depends really on the project.
xhtml is a step in the direction of establishing and encouraging an open nature to the content of the web. Where in the spec does it say "don't render the page if a tag isn't closed"? It's up to the browser render engine designers to deal with your fu*ked up markup, not spec writers.
"It gave people are way to draw a line between traditional table driven HTML layouts and modern XHTML / CSS approaches."
Exactly. It recognizes the value in markup describing content and information separate from how it should be rendered on a two dimensional monitor - something I feel you're missing or de-emphasizing.
If you really had to drastically alter the semantics of your markup to significantly change how it was rendered in browsers then I think you might need to enhance your working knowledge of css.
It might not appear to benefit /you/ much, it's a pain in /your/ ass to remember to close tags and think about the structure of the information you design but these notions hurt the open nature of the web. They hurt both machine-machine communication and hci.
Do you run your sites through a screen reader? do you care?
I'm glad someone actually had the same idea I have about programming and web development --> embracing flexibility over strict rules, because strict rules will only limit potential creativity.
Gary: To my know XHTML is derived from XML (which by itself will hopefully be replaced by JSON soon). W3C says:
"Once a fatal error is detected, however, the processor must not continue normal processing" (http://www.w3.org/TR/REC-xml/#dt-fatal)
One of these errors is the failure to implement a well-formed document. So you have one mistake in your layout that only shows under a certain condition and suddenly a majority of your viewers won't be able to see your site. Another problem with XHTML is that for example FireFox and a ton of other XML parser implementations cannot incrementally parse an XML document. I'm not sure if the strict rules of the format are to blame, but it causes your page to not render at all until *all* markup is downloaded - how is that for usability?
I'm also surprised you think I de-emphasize web standards in any way. I gave XHTML credit where credit is due. However, I disagree with the notion of XHTML offering any advantage for separating content and presentation - HTML is just as good (or bad) for that purpose.
About my knowledge of CSS: It is absolutely unrealistic to not change your markup for a major re-design on 99% of all pages. CSS Zen Garden is not the real world. Its creator spend tons of time coming up with the most flexible (read: most verbose, least semantic) markup to allow for all kinds of transformations. The designers who show their skills on the site spend dozens of hours pushing the limits of what can be done and for big parts cheated. By cheating I mean they used techniques that would not work if the content of the page was not static. But again, you are likely to misunderstand me here. I think CSS Zen Garden is a great project and I think the notion of never having to touch your markup again one day is great. I am just saying we are not quite there yet (as far as real world projects are concerned) and I'm also unable to say if CSS / HTML are ever going to be the standards to pull it off with.
PS: I'm sorry about your comment being detected as spam. Please report the incident to the folks at Akismet - I'm sure it was nothing personal ; ).
Couldn't agree more with this! XHTML did a good job of bring standards to the attention of developers but in reality 99% of websites require no more than HTML 4.01. Obviously we're not the only ones who think this becuase HTML 5 would never have been born otherwise!
I like the idea of microformats as well but I see them more as a testing ground for possible new types of tags which could be introduced in future HTML specs, something like a <hcard> tag etc. Microformats are a standard way of marking up data, why not make them part of the standards.
@all: I just fixed the buggy auto-link code for the commenting system and added a Comments::admin_edit function and used it to correct wrong links and quirky stuff in all comments above. We will also add a preview comment and 15 minute edit function for everybody soon. Sorry for the inconveniences in the meantime.
Without re-iterating what many have already said in the comments above, I believe you are spot on with your assertions. I feel like I get in this debate every other week, and I have yet to find someone to show me the real value of XHTML versus HTML - from any aspect. Eliminate the pipe dreams of 'well, I can do cool stuff with XML and parsers...blah blah blah' - things that will never get done, and you are left with: HTML.
I usually use XHTML 1,0 Strict pretty much for the same reason as Edward but just as him I rarely use the advantages it gives. However I would prefer to have it if my boss ever come and ask me for something that require these advantages.
I don't think it's any harder to make a website with XHTML Strict instead of any of the transitional/html variants, you just have to get used to it.
The biggest advantage people see in XHTML is that it is supposedly better
separating content from presentation. That is BS.
Now I can't remember for sure so correct me if I'm wrong but do the tags acronym, abbreviation and cite exist in HTML? I prefer those before bold, italic and so on because they describe what kind of text it is and not how the text looks.
The cite and blockquote tag would for example be useful in combination with xml if you ever wish to index all the quotes in the world.
Andreas> Hi, the tagsets are the same. All that changes is the syntax and prescribed user agent behavior.
You should consider the mass of existing webpages marked up in a presentational way. This is not to blame all the coders! Tim designed the html as a way to encode presentation, so face it :)
so i suppose that when you look just for the cite element, you will barely scratch the surface.
emilk: Not quite true, some tags like font, center, etc. are deprecated in XHTML 1.0 strict. http://www.w3schools.com/tags/default.asp has a very nice list. However, most presentational elements like big, small, b and i etc. are not.
felix>
i and w3c can not agree :)
there is no center as well as font element defined in
html 4.01 strict dtd
http://www.w3.org/TR/REC-html40/sgml/dtd.html
the rule is as far as tagsets are concerned:
xhtml strict = html strict
xhtml transitional = html transitional
...
at least it is my strong belief
@emilk: Ah ok, I misinterpreted the site I linked to ; p. Thanks for the correction. However, with that being said I have lost even my slightest bit of appreciation for the xhtml format. Its really just a philosophically crippled version of HTML 4.01, not sure why it even has its own boring specification with nothing new in it ; ).
So this also means that HTML 4.01 strict does not allow for target attributes / iframes, right? Not sure if I like that given the lack of other ways to create css / js isolated containers within your page.
Writing web pages as well-formed XML documents might seem useless to you now, but conforming them to a well-known, easily-parseable and sometimes native data type in many programming languages allows these to be used in the future in ways you can not foresee right now.
The company I work at does some quite amazing stuff with Flash and XHTML , which would not be possible with plain HTML, and that could not have been predicted a few years ago. (I'm sorry but I need authorization to mention details, if anyone's interested.)
I think it's a matter of taking a step back and considering different possibilities of what could be done with the websites you're developing, only a few of those being screen readers, data mining and source parsing for other uses, which to me seem like enough.
Perhaps some sites could be excluded from this notion, but since we can't predict, we can't exclude the possibilities yet.
Bruno: What makes valid / strict XHTML easier to parse then HTML? If you think that I promote writing poor HTML just because you can then you got me up side down ; ). I am saying poorly written HTML should display, not that you should write it. I know there are more XML parsers then HTML parsers out there, but that doesn't say a lot. For one I think XML is a terrible format and exceptionally difficult to parse. I am not saying HTML is better, but I think it is fairly easy to transform valid HTML 4.01 strict into valid XML making neither one much easier to parse.
Hi Felix
Unusually, I find my views differing to yours. I've always considered markup to be 'code' - to be interpreted by the client viewing program (i.e. a browser or other). We would never expect our php or javascript interpreters to continue after a parse error within our code, so why should we expect the client program to decide 'what we meant' when it hits a parse error in our view 'source'? We do at least, still have a choice if we want the client to take that decision on our behalf: don't use XHTML :).
Whether XML is good or easy to parse is not really the issue - if we choose to use it, we should test the output with the same enthusiasm as we do with our other code (it's pretty easy - just look for the green tick in Firefox).
Not that I always get it well formed (and/or validated), but I do get incredibly annoyed with myself (not with the Standard) when I don't...
GreyCells>
Hi, in your parallel with code, there is a catch.
In program, the instructions are the merit of the code.
This is not the case with html page.
There it is the content that is the king, the markup is just added information for browser to get better presentation.
So where there is error in this supplemental info, it is really bad idea not to show the plain content as xhtml demands.
Does this give sense to you?
Bruno>
whats the difference in walking html dom or xml dom?
@emilk: With an [x]HTML page, the markup is the 'syntax' (as per var $para = 'Some value'; in php) and the information has to be 'assigned' using the proper syntax ([para]Some value[/para] (sorry, can't do lt or gt)).
Granted, it is generally only interpreted by a view client, but with other technologies (Javascript, XSLT etc) you are virtually programming logic for the interpreter (e.g. a nested list will often be 'interpreted' by jQuery to show top level [li]s and hide nested [ul]s unless the top level [li] receives focus - a simple navigation menu).
We would never expect php to decide that you meant to create a nested array when you introduced a syntax error, so why should the view client to do the same just because you missed a closing tag (the equivalent of forgetting to close an array definition with ');'.
Strictly, the markup is not for better presentation - it is for semantic classification of information. Unfortunately we don't 'buy' raw information - we like it wrapped in fluff, to make us part with our time/money (ever tried selling a wireframe to a client?).
@felix and emilk: I believe unclosed tags adds a whole lot of complexity to parsing markup code, but I don't come from a Computer Science background, and don't consider getting too deep into that. A huge portion of browser code is basically dealing with tag soup, something which the XHTML standard simply aims to remove.
---
Reading these new comments, and some of the old ones again, I realize the problem itself isn't XHTML. I have my problems with it, can't deny, but I think it's a nice step towards something really good. The problems are quirky rendering engines, slacky developers and the lack of an effective way to isolate user generated markup from the structure of the page. There's nothing wrong with the standard itself (or its intentions).
I agree that there's a myriad of tags and structures lacking in the current standard as well as deeper separation from content and presentation is needed, and there's huge number of hacks being used to overcome these limitations. Class attributes are not meaningful enough, putting navigations inside unordered lists is not going to magically show people or software how to navigate a web site, but it's organizing in a predictable way which can be used and improved in the future.
Strict XHTML also helps a lot when having to deal with markup left from previous developers: validating code tends to be cleaner and easier to understand and change than slacky tag soup. And the only way to enforce this is forbidding the user agents from rendering invalid code. And if I'm not mistaken, Slashdot implemented a new layout back in 2006 with barely any change to the underlying markup.
There's no way I'd disagree there's still a long way in the direction of web markup that works for everyone, in all levels, but XHTML is not by any means a step back from HTML.
Oh boy Felix, you opened a can of worms with this one! ;)
I don't have a particular preference with regards to html or xhtml, I use the right tool for the job. I do make sure my documents are well-formed and that is all that matters really.
The Web standards movement has really brought a legitimacy and, crucially, an expectation of professionalism to our industry that was sorely lacking for many years and long may that continue. To build a website with ill-formed documents without prior thought into how best to do so is (rightly) looked down upon by any proud coder :)
By the way, I too have big hopes for html 5, it will bring a lot of features to the table like offline storage, new media elements and improvements to the DOM. I am also looking forward to the implementations of web forms 2.0 to bring MUCH needed improvements to the way we build web applications. Why do I even need to include identical javascript AND {insert preferred server-side language here} validation rules in my app? Should the form itself not do this?
Ah, the future will be grand... if we ever get there ;)
Cheers;
Poncho
GreyCells>
i understand your view.
you came to such conclusion because you are buying the "semantics" of xhtml elements. yes, it is written everywhere, but go and judge the tagset (even the strict one) for yourself!
i find it to be mainly typography.
html5 is first real attempt to add semantic and meaningful markup (for the domain).
i acknowledge that they (html and xhml guys) tried, but removing the menu element, and creating nearly synonyms with more letters for [b], [i] ([strong],[em]), when there is so much left behind (all the microformats stuff deserves its elements), eh, this is serious?
lets face it: the meaning is there in those words, in the content.
the added paragraphs and stuff around is just icing on the cake :)
so i conclude for myself that not providing the content when there is something broken in the markup is a sin.
@emilk: Slightly off topic, but actually, I came to the semantic 'conclusion' because that was the intent of Tim Berners-Lee et al - I haven't bought anything...
Now, if you're talking about a lack of scope in the elements available, that is a different issue (and not just from Felix's post). To have progressed through four iterations of HTML and still only have the extremely limited widget set we have for forms is downright criminal - but it underlines the semantic intent of the web's designers - it simple wasn't that important.
In all forms of communication, syntax (markup) is equally as important as content:
'Eats shoots and leaves' or 'Eats, shoots and leaves'?
We humans can parse that and make a judgment call as to which is correct, depending on the context - machines cannot, so should fail safe. A document that is not well formed should not display (fail safe); a document that is well formed but does not validate against a dtd/schema should display - as it currently does. Saying a browser should know what to to when there is something broken in the markup is like saying the PHP interpreter should not fail if I write $content = 'Let's go to Bert's':
It is the 'well-formed-ness' that I believe we should always deliver - with the same discipline that we apply to our code syntax.
> Give me a break, but this is madness.
Madness ? This is standaaaaaards.
> But more importantly: If you ever tried to completely change the design of an XHTML page I know that you cheated and changed the markup.
Yes I did, no I didn't, yes the system was in production. Of course, you can only do that if you actually thought of it when your first wrote the XHTML.
> The view is so important that no trivial error in its markup should cause it to be completely inaccessible.
Trivial errors are trivial to fix.
> Another problem with XHTML is that for example Firefox and a ton of other XML parser implementations cannot incrementally parse an XML document. I'm not sure if the strict rules of the format are to blame, but it causes your page to not render at all until *all* markup is downloaded - how is that for usability?
Blame the parsers, not the standards.
Besides, if your page is so large that downloading it takes a few seconds, it's time to re-think your presentation model. A good Web page is only a few screens high.
> and it doesn't increase your sex appeal.
Neither does posting on a technical blog. But that doesn't seem to be a real problem, does it ? ;)
All in all, my point is that it's just a matter of taste.
I compile my code with "-Wall -W -Werror" so I'm pretty happy when the whole page breaks if I make a mistake. If I'm doing things wrong, that's my fault and I expect the renderer to tell me what I did wrong.
If you want something that has some kind of failsafe, that's fine with me. But please stop blaming the strict standards, I'm tired of seeing the same complaints again and again :)
XHTML is a step towards semantic markup. I don't care which of HTML5 or XHTML2 will the the successor, but semantics have always proved to be the best long-term solution.
Folks, see, in a way I totally agree with you graving for something ultra-strict. But I think our problem is that we are all reactionary about it. We have been treated poorly by quirky browsers and by legacy projects containing messy html. But truth remains, for every one of us "elitist" web developers, there are 5 people who have a myspace page, a page for their band, a page for their family, a page for their dog and a page for their political believes. XML is an unbelievable difficult standard and I myself hate dealing with it. Promoting XHTML as a new standard over HTML is not just wrong for its lack of features, it is wrong because it is against the nature of the web.
The technology of dealing with broken markup has been developed. It works just as well for HTML as it does for XHTML (which you guys should know best since you send your "XHTML" as text/html). So if XHTML was to come and say browsers should create a detailed problem analysis for broken markup in their console instead of just "swallowing" the errors as they do now, but then use their quirks-mode to display at least something - I would welcome this very much. Speaking as a web professionals I think we need clear standards to follow. But XHTML is just way to radical. Too radical in the way it handles errors. Too radical in the way it ignores current real world problems.
And if you guys are going to continue to compare HTML to a programming language then I don't know what to say. Except maybe that I see a huge difference between a format used by easily half a billion people compared to the few million who use a certain programming language.
I have been using xhtml 1.0 Strict or Transitional for about 5 years now, and in all honesty have no good reason to do so, as I am serving the content as text/html. For about as long as I have been using xhtml strict I have been reading articles such as the seminal piece by Ian Hickson (http://hixie.ch/advocacy/xhtml). I've known for a long time that I really should move to html 4.01, however, for whatever reason, have never made the move. I jumped on the bandwagon a long time ago, and just haven't ever found the motivation to get off.
I will say though, that striving to achieve validation with xhtml strict, even using the misguided text/html content type, gave me something to shoot for when building web pages early on (the last time I visited the w3 validation tool was probably over a year ago). It gave me a goal and really helped guide me towards more standards compliant, accessible web pages. Having this goal I'm sure laid the foundation for a lot of people who cared enough to pay attention to standards.
Anyway, this is perhaps the motivation I need. The next site I build from the ground up I will be using html 4.01. It's something I believe I should have done a while ago.
XHTML is joke in your town - everybody get get get down!
I think that your main argument against XHTML Strict should be directed towards CSS instead. As you say "...I know that you cheated and changed the markup." I believe that if CSS would work as intended and really let ppl describe anything that has with presentation/design and do, then XHTML would work as intended. That is being purely data markup.
On this note, perhaps there should be a way to tell Cake's HTML helpers to generate HTML tags rather than XHTML tags. I would prefer to use HTML 4.01 strict, but if I do, Cake will helpfully close tags like IMG and LINK with "/>" instead of just ">", thus making my markup broken no matter how you look at it. :)
@Joe: Thats simply never going to happen you can make webiste as standards complient as you like, but unless its incredibly simple then there will always be stupid errors which will work fine in any browser. I always aim for transitional, like felix said its the content that the most important and display layer breaking my page cause i have a stray depreciated attribute hanging arround just isn't worth it.
It shouldn't matter that much as long as you dont have things like frames and open tags cripling your document.
I don't think XHTML is on the presentation layer. It's just meant to give data meaning, not to present it.
About XHTML strict, tiny errors could trip up the parser that is trying to cull meaning from the markup. Whether you use strict or not should depend on what application you are developing. If the application has to deal with ontology, logic and proof then going for XHTML strict would be the most appropriate. Ok, so not many people use XHTML for those purposes :-) But the future is the semantic web (an intelligent web), and it is necessary to start pushing harder if we want to get to a truly semantic web.
Some info on XHTML and RDF
http://www.w3.org/MarkUp/2004/02/xhtml-rdf.html
This discussion has been going on for a bit, but I feel I just have to add my 2 pennies to this:
Nobody here is serving their XHTML documents with an xml Mime type, since otherwise your site would not work in IE.
Since you're not serving it as xml, but as text/html instead, the parser will **not** stop interpreting your page, since it is just interpreting it as html & does **NOT** stop rendering the page when there is an error.
HTML & XHTML have the same tag set, just with a slightly different syntax: they are both as semantic as you want them to be, within the boundaries of the specification obviously.
All that said: I work as a UI dev lead in a fairly big organisation looking after /developing websites with over 500k unique visitors/day & that is only the small part of the business: the other part is well in the millions and we are using:
xhtml 1.0 strict...
You can check it here, should be valid as well: BBC
I don't want to say that xhtml is better or worse than html, it just doesn't really matter right now, since they are both served up as text/html.
I found that in teams with lots of developers, the strictness of xhtml & the syntax staying the same (i.e. disabled="disabled", rather than "disabled") help the team to output better/more consistent markup (not code as some people seem to think).
That said: if html is more up your tree: go for it.
Also: we validate all our pages, **but** if there is a good reason why something breaks the validation, we don't care: validating your page is just a tool to check whether you markup is well-formed and can help you tracking down CSS bugs.
Validation, as some people mentioned, can be difficult when there is a CMS, ads or similar on the site. I also think the W3C has deprecated some elements & attributes that make no sense (the 'start' attribute in 'ol's comes to mind...).
On the comments about changing markup when redesigning pages/sites:
Often when a site gets redesigned, the information architecture of the site changes & hence the markup must change as well, if only to stay semantic! That said: with some foresight and addition of some hooks with id's & classes, your markup can be very flexible, without suffering from divitis or classitis.
As I said, just my 2 pennies & sorry for the rambling!
Happy standard compliant developing everybody!
You are a joke. I really can't believe any one serious about business would let you post on their website. Anyone that is currently using XHTML isn't going to be convinced by your schoolyard tantrum about it. I know you are young, but you I think you act even younger than you actually are. Tell me why it is wrong to use it and how it is going to be detrimental to my website. For now, as long as it is sent as text/html nothing bad can happen, unless you consider well formed code bad. This is just like the Apple vs. PC argument, no one is ever going to win and guess what? It doesn't matter. Good luck with your career. In a few years you'll look back at your blog posts and think "God, I was being a douche."
Jason: I made a lot of points why it is wrong to use XHTML in the post and a few others in the comments below. If you want to comment on any of them, go for it. Personally I'm much more interested in HTML5 and other technologies that want to improve the web. XHTML reduces features (target, iframe, etc.) and introduces ultra-strict rendering rules. So for me it creates more problems to use XHTML then it solves -> I don't use it.
@Felix, HTML5 does not mean you can omit tags, forget to close them, etc etc ... I think code, whatever layer it is, should be well formed, clean, and reasonably simple to read/understand. This should mean less problem for parsers which means more speed for both clients and servers (when layouts are elaborated there as well). I do not get all this complaining about XHTML and 1.0 is widely supported and it guarantees reasonable results even in non A-Grade browsers. As XML brings data and should be well formed, XHTML or whatever DOCTYPE you like brings the layout. Strict means you are following more rules and if you want to forget a layer just because is the "latest one" ... well, you should consider design rather than web programming/development, and forget contrasts cause lines are more important for the structure? As summary, as far as I remember I have never had a fatal error problem in almost 10 years, maybe I have been lucky? In any case an error means somebody, possibly not the parser, did a mistake somewhere ... do you think it makes sense to blame a standard for this? Just my 2 pennies. Regards
Arriving (very) late to this discussion. My gut assumption here is that most, if not all, of the responders to this post are primarily back-end developers? My primary role is that of front-end developer (html/css/js) and I've been using XHTML Strict exclusively for the last couple years. My response to your statement "the slightest mistake in your markup will cause your page to NOT RENDER!" is this: duh.
To me, that's exactly the point. It may be easy for a back-end dev to think that the fidelity of the original design is secondary (or lower) in priority to back-end code. And I can't exactly blame you. But my entire job is predicated around the idea that I'm taking a designer's vision and building it as precisely as possible. Now, if that designer is also you, it's your choice whether to code your front-end properly. But in a multi-person team, I don't have that luxury, and I don't allow other front-end devs that luxury either.
@Andrew Jones: I think you've got it exactly wrong, and your view is diametrically opposed to the very notion on which web development (as well as browser development) is predicated.
Unless you're relying on proprietary browser extensions, absolute 'fidelity' of page rendering is a pipe dream at best. It is completely impossible to get pixel-perfect renderings of your designs across all browser/OS platforms. Of the dozens of combos, you're lucky if you even hit three. If your designers expect fidelity, they're working in the wrong medium; tell them to go back to print.
Additionally, as graceful degradation is a core tenet of browser implementation as well as good markup & code, the idea that one misplaced ">" would completely break the entire page is tantamount to replacing your site with a banner that says "You can only view this site on IE6", because you're coming from the same mis-informed idea that 'if your browser can't render this *exactly* right, then you get nothing!'
It's people like you that started to destroy the web when IE6 was peaking; and everyone who has failed to adapt since then has been either laughed out or kicked out of their profession.
@Nate: Wow, I had no idea I was responsible for destroying the web. My bad.
I'm absolutely not saying that getting pixel-perfect rendering in all browsers is the goal. Even if the page looked 50% different from the original design, that doesn't change the fact that if I mess up the code, something will break. I don't know why this is such an unthinkable concept. Leave off a closing ">" and it breaks. Them's the rules.
Yes, it's nice when browsers are "forgiving", but if you code it properly the first time, you won't have to worry about being forgiven as much.
And on a side note, yes, it is absolutely the job of a front-end developer to make the page look as much like the original design as possible. I've never had a designer give me a comp and say, "just get close". So if you can't make it work in every browser (with some graceful degradation in IE6), then you either need to go back and negotiate with your designer, or get better at your job.
I believe the movement to subvert XHTML will harm the Open Data Movement, the Linking Open Data Community Project, and, ultimately, progress toward realizing the Semantic Web.
If we want to make the Semantic Web a possibility, then we need HTML serialized as XML. Thus, we need XHTML. We need to understand that HTML is no longer simply a presentation format, but that it is also a data interchange format.
@Ben Ramsey: I agree, and I don't think anyone has anything against well-formed markup in and of itself; that's not the point.
I think of the debate as being analogous to the debate between static and dynamic languages. XHTML takes the static typing approach of saying, 'if you don't implement this correctly [regardless of whether or not it's *functionally* incorrect] then I'm not even compiling this for you'. Whereas in dynamic languages, it'll continue to run, and as long as you're not leaving the engine in an unstable state. However, your unit tests (a.k.a. markup validation) will bitch at you until you get it right.
This is, IMO, the correct approach. We have a system for determining the 'correctness' of a document, but expecting a lack of correctness to totally break your page is like not even allowing your application to execute without all your tests passing. Now, if you want that level of strictness, that's your decision to make, but it shouldn't be made for you by browser vendors or standards bodies.
@Andrew Jones: I forgive you. :-) But now you know, and knowing is half the battle. ♪ G-I-Joe!! But seriously, as much as I'd like to "just code it right the first time"... well, sometimes I don't, and we've all had errors that only get caught in production. I guess we can't all be perfect like you. :-P
Hehehe... kidding, kidding.
This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.
I choose XHTML *purely* for the potential wins of being XML -- something I'll freely admit I almost *never* have taken advantage of. Other than that, there isn't a major win, no. That's why I always use XHTML *Transitional*. Strict is, well, too strict. I'm all about semantic markup and separation of data and formatting when possible, but I like being able to have flexibility.