Search

Siding with HTML over XHTML, My Decision to Switch

Posted: June 30, 2008 Comments(16)

The HTML vs. XHTML discussion has been lingering for an extensive amount of time. There have been many solid arguments put behind each, and more often than not, the consensus from many authors isn’t to choose one over the other, but to justify your choice. The idea was to make an educated decision and stick with it. I’d like to skip the formalities in explaining the fundamental differences between HTML and XHTML in favor of a discussion surrounding the characteristics which helped shape my decision to use HTML after years of writing XHTML.

My history with XHTML

For a long time I wrote XHTML without a second thought. I loved the additional rules and restrictions with writing syntax, mostly because I was so used to seeing poorly written markup so often. XHTML was so much prettier, more organized, nicer to work with; it had to be. I liked the fact that XHTML needed to be well-formed, and I always wrote my markup in lowercase anyway. It seemed like the additional rules were aimed at authors much like myself. I was quick to adopt XHTML as my language of choice.

On top of that, a lot was being written about XHTML. Many of the designers and developers helping me learn more about my trade were publishing XHTML. Many were vocal about their choice, listing supporting factors in comparison to HTML. It’s comforting to see those you look up to sharing the same techniques, so writing XHTML seemed like a great fit.

Recently, however, I’ve been taking the decision between HTML and XHTML a bit more seriously. I’ve taken some time to examine the differences between the two technologies and how I can apply those differences to what I know. There are fundamental differences between XHTML and HTML, and it’s important to make an educated decision as to which you’ll use.

What prompted my switch to HTML?

Using XHTML began to make less sense for me. The fact that writing XHTML requires an author to follow more rules was a personal preference, which turned out to be partially inappropriate (in my opinion). I wasn’t considering the grand scheme of things; the Web in a general sense.

What started to get under my skin was the fact that I spent a lot of time writing XHTML, but serving it as text/html. Why? I was serving text/html because the servers to which I was publishing are configured similarly to 99% of the other servers powering the Internet. They’re not configured to serve XHTML as application/xml or application/xhtml+xml. We (as designers and developers) should be happy about that, however. Internet Explorer (including 7 and 8) will not support XHTML served as application/xml or application/xhtml+xml. IE is by far the reigning browser champion and will remain so for a bit of time. The fact the IE doesn’t support our use of XHTML is a major show-stopper, don’t you think? To circle back, it started to become irritating that I was publishing a document in one way, and serving it in another.

Just to be clear, I was publishing XHTML 1.0 which (technically) can be published as text/html, but in a way it seemed counterproductive to me. Additionally, that ability (probably) won’t be available in future revisions of XHTML. More on that later.

Incorporating client work

I try to base many of my opinions on real world applications as much as possible. To be more explicit; I try to apply things to client work instead of personal projects. When we’re writing our own documents, of course things are going to work out how we planned (at least we hope so, and we’ll work on it until they do). When it comes to client work (and therefore ‘the rest’ of the Internet) things are quite different.

Publishing content on the Web is in no way limited to professional developers or designers, much of the reason the net is so active is because anyone can make a website. Sure, we (as knowledgeable professionals or hobbyists) all hope to make the Web a better place by doing our part in publishing documents with semantically rich, valid markup, but the reality is that those documents are rare. It’s important to keep in mind the true nature of the Internet; an open platform for information sharing.

The reason I raise that point is because all the the work I do during my workweek is to build websites for clients to use. They’re the ones managing the content, controlling what happens to their website after it’s pushed live and all questions about the CMS have been answered. It didn’t feel right to me that the documents I was handing over had this strict set of rules embedded within them. Of course, technical details such as what DOCTYPE was being used was hardly a topic of conversation, but that fact remains that clients were given the ability to alter the markup of their website via WYSIWYG editor.

Sure, the editor we use boasts valid XHTML (like many WYSIWYG editors), but more often than not it would only be a few days before markup errors would sprout up throughout the website. Had the site been served with the proper MIME type, my office would be getting phone calls with every update the client tried to make (which in turn prevented the document from loading); defeating the purpose of giving them access to a CMS.

Publishing XHTML, and therefore imposing the associated strict ruleset, didn’t seem like the best solution any longer.

The opinions of browser vendors

Some time ago, I came across an article which included some great links to publications by major browser vendors outlining their preference concerning HTML vs. XHTML:

There is some great information provided in those articles, especially the interview with Håkon Wium Lie. A quote from that interview, which has been included in many articles surrounding the HTML vs. XHTML debate, is worth reading at least twice:

XHTML2 has some very good ideas that I hope can become part of the web. However, it’s unrealistic to think that all web authors will switch to an XML-based syntax which demands that browsers stop processing the document on the first error. XML’s draconian policy was an attempt to clean up the web. This was done around 1996 when lots of invalid content entered the web. CSS took a different approach: instead of demanding that content isn’t processed, we defined rules for how to handle the undefined. It’s called “forward-compatible parsing” and means we can add new constructs without breaking the old.

So, I don’t think XHTML is a realistic option for the masses. HTML 5 is it.

I seem to lean quite a bit toward Mr. Lie’s last statement: “… I don’t think XHTML is a realistic option of the masses. HTML 5 is it.” That’s a very powerful statement coming from someone for which we all have a deep respect. His sentiment ties closely with my experience in Web development, especially with client projects.

Looking to the future

Rereading a piece like The Road to XHTML 2.0: MIME Types was also a major reality check. One of the major take home notes from that article is: “Although the spec is not finalized yet, all indications are the XHTML 2.0 must not be served as text/html“. That’s a major implication which could have an adverse affect on your workflow.

It’s also interesting to compare XHTML 2.0 to HTML 5. From the HTML 5 spec:

XHTML2 defines a new HTML vocabulary with better features for hyperlinks, multimedia content, annotating document edits, rich metadata, declarative interactive forms, and describing the semantics of human literary works such as poems and scientific papers.

However, it lacks elements to express the semantics of many of the non-document types of content often seen on the Web. For instance, forum sites, auction sites, search engines, online shops, and the like, do not fit the document metaphor well, and are not covered by XHTML2.

This specification aims to extend HTML so that it is also suitable in these contexts.

XHTML2 and this specification use different namespaces and therefore can both be implemented in the same XML processor.

HTML 5, in general, seems to be a more attractive solution taking into account the work I find myself doing most often. I hope to soon devote more of my personal time to following the development and implementation of HTML 5 as it matures over the coming years.

Taking a step back

I realize that the bulk of this article outlines some faults I’ve personally found with using XHTML over HTML. I’m partially disappointed in that, but on the other hand it was a matter of a decision I had made that needed to be disproved in order for a change to happen. I didn’t want to make this choice lightly, I wanted to educate myself more on the core differences between the two and try to determine the better choice for me. I wanted this article to be based upon my personal reasons for switching, as opposed to a piece outlining the pros and cons of each. We can all accept that there are definite pros and cons to whichever decision you make.

I know I’m not alone in saying that I prefer the restrictions imposed by writing XHTML over HTML. That hasn’t stopped me from continuing to pay attention to the details of my markup, even if it is HTML. I still write everything in lowercase, and I continue to keep everything well-formed. Although end tags aren’t required, I can’t help but to include them (where applicable). I still quote my attributes values as well. At the end of the day, the only true noticeable difference is the lack of self-closing tags and a different DOCTYPE.

You should definitely have an opinion regarding your decision to use HTML or XHTML, and it would be great if you’d take a minute to leave your thoughts in the comments following this article. I’d love to hear some applicable reasons supporting your choice, based on your experiences as well as the requirements of your workload. If you’ve got some things to share, please take a minute to leave your mark and/or respond to someone else’s.

Related Content

  1. Year in Review: Highlights from 2008
  2. Current Events: The Official End to XHTML
  3. HTML Email Boilerplate v0.4

Categories

Categories Development, News, Opinion

Tags

Tags , , ,

Get my newsletter

Receive periodic updates right in the mail!

  • This field is for validation purposes and should be left unchanged.

Comments

  1. I’m a XHTML guy myself in part for the same reasons you were using it. I like the restrictions. I’m looking forward to XHTML 2 more than HTML 5, but I’m not overly hopeful in either case. The people making the decisions are constantly bickering and it effects productivity and sound decisions. I find these groups are the real problem with the standards. We shouldn’t have two paths (HTML or XHTML). There should just be one. Both have promising components, but they need to converge. IE, as always, is the headache in really moving forward. I’ve stopped supporting IE at my site altogether in protest of them (not that they care). If these work groups working on the XHTML2/HTML5 specs can’t get their thumbs out of their arses then I might find me a new hobby.

  2. Jonathan, i’m in the same boat as you.
    I was also coding everything in XHTML. Maybe i was a bit infected by the hype about it… But there appeared some problems in developing very huge sites which has content from different suppliers. Will say that the content often was delivered in HTML and, as a consequence, integrated in my XHTML document. BAD!

    And i had made the experience, that many backend-developers don’t care about validation and well formed documents. So they don’t care if it’s an XHTML document. They throw in HTML code. BAD!

    So i reflected myself and searched the web, why it should be better to use XHTML. I didn’t found any real reason. But i found some drawbacks on using XHTML in this Article: http://www.webdevout.net/articles/beware-of-xhtml. And my eyes were opened!

    So i do write my HTML (strict) like it is XHTML: lowercase, well-formed, include end-brackets, etc. And i can sleep well…

  3. You know, I never really looked at the differences this way. I just started writing in XHTML cause it was the newest way.

    Very interesting article! I will have to do some reading myself on this subject, maybe even make the switch myself.

    @Ole: Thanks for that link! That article was very helpful in comparing.

  4. Jonathan, you’re not alone. I had also been working exclusively with XHTML 1.0, until recently, when I discovered the HTML4 strict tag. It didn’t take long to figure out which works with less hassles, and provides the same result. I’ll be watching the HTML5 spec with interest, and using XML where it belongs – in the back-end.

  6. Hi Jonathan,So basically if you serve your xhtml as text/html there’s no difference between it and html. That leaves the doctype only beeing important for code validation, right?

  8. I suppose that HTML5 is good enough if the only interoperability you are concerned with is that between web page server and desktop browser. But it is massively underspecified as a standard for exchange of web documents between web applications. Likewise the CSS2 class libraries, which are virtually worthless for the purpose because the CSS is typically defined in site templates rather than in the web documents themselves.

    For example, I can go to any number of web applications and find myself creating different custom markup to identify a footnote call or a footnote, including Mr. Lie’s Prince software. And were I to attempt to exchange web documents among, e.g., Wikimedia, WordPress, Google Docs, and Zoho Writer, my only hope is to recode content manually.

    One might facetiously call it an elemental problem, but the interoperability barrier is no less real. HTML5 is designed for web browsers, not for exchange of web documents by web applications. With the steady march of software from the desktop to the web, HTML5 is a woefully inadequate solution.

    I think it a mistake merely to assume that one must bow to Microsoft’s wishes; the company has not been a good industry leader in regard to interoperability. There are both benefits and drawbacks to designing the web for interoperability rather than for Microsoft. Sites may get less traffic for awhile, but every page MSIE cannot render puts more pressure on Microsoft to follow rather than to dictate the future of the Web, creates incentives for users to switch browsers.

    Web app editors write to a Tower of Babel assortment of custom microformats, following the same incompatible path pioneered by desktop office software. That the non-Microsoft browser developers are too blind to recognize the need for web document exchange formats for web apps is scarce testimony to the wisdom of their market analysis. Microsoft has XAML/Silverlight holding two-way conversations with MS Office. Of course Microsoft prefers that the other browser developers go with HTML5.

    I do not know whether the web app document exchange standard will be W3C WICD profiles, OpenDocument, WebKit, or some other. I just know that — to paraphrase Mr. Lie — HTML5 is NOT it. HTML5 is for browsers only; it is not even in the running as a web app document exchange standard.

  10. @marbux: Of course i disagree with your interop assessment, but I wondered how it is that you’re missing the point. I think you confuse web applications with legacy desktop – client/server application model. And that confusion leads to the mistake of trying to transfer the desktop document model to one that could adequately service advancing web applications.
    The first mistake you make though is in assuming that HTML5 is a web document format for web applications. IMHO, it is the combination of HTML5 (structured content), CSS3 (portable presentation layer), JavaScript (portable processing logic) and DOM that feeds the appetite of advancing web applications. In this respect, the WebKit document model provides us with a rather broadly shared focal point for cutting edge Open Web application development.
    Although I would agree that HTML5, CSS3 and emerging JavaScript libraries overlap and duplicate functions so effusively that one could assume some sort of independent design at work, my opinion is that this should be expected in a world where HTML4, CSS2 and a world wide flood of hacks and web application specific innovations defines our reality. Backwards compatibility matters. Developers and designers mash things together and push forward best as they can using whatever aspects of emerging methods that work.
    It’s all good, even if confusing, until developers and designers come to that great fork in the road ahead; the choice between the Open Web and Microsoft Web. The Web is going to break. A more serious separation looms than anything imagined by past IE style innovation cloaked efforts to embrace, extend, extinguish W3C standards.
    Not to diminish WHATWG, Mozilla and Adobe RiA, but it is into this great breach that the WebKit layout/document model surges. With the W3C trailing behind, scrambling for relevance, and hopefully recognizing how important it is to the future of the Open Web that they find validating consensus for the methods and needs of Open Web developers, designers and vendors.
    IMHO, in the very near future, developers and designers will find themselves having to choose between the WebKit layout/rendering/document model, OR, the Microsoft XAML-Silverlight-WPF model. Notice I don’t include Adobe RiA in that choice. This is because the Adobe RiA supports and implements the WebKit layout/document model. So does the Blackberry Thunder, the Apple iPHONE, and future versions of Nokia devices. Browser support includes Safari, Firefox and Opera via compliance with ACiD3.
    Here’s where I think you make your mistake; you assume that a web application is like a desktop-client/server application. And from there you extrapolate the fatal document model transfer.
    The desktop application model is one where the layout (rendering) engine is application specific. It’s built in. When a document is loaded into application memory, it’s subject to the application layout engine and related feature sets. Application specific document formats perfectly reflect application specific content, presentation and processing logic.
    Even when we XML encode these binary formats, effectively separating content-presentation-logic, the presentation and processing logic layers remain stubbornly application specific. In fact, the beauty of XML for office suites like OpenOffice and MSOffice is that XML 1.0 was designed as a language for writing application or process specific languages. The problem of course is that application specific presentation and logic layers are not interoperable (portable) unless applications in the exchange implement the same layout engine and feature set designs.
    But then, XML 1.0 was not designed for interoperability. It truly is a language for writing specific purpose languages. And that’s how both OpenOffice and MSOffice use it. Although I continue to believe that the application specific OpenOffice ODF presentation layer could be made interoperable using a RDF metadata approach, I doubt this will ever happen. The failure of the OpenDocument Foundation to push this approach through OASIS speaks volumes about the intent and determination of prominent ODF vendors to stay the course.
    So, here comes the money question; where’s the layout/rendering engine for web applications? What is a web application layout engine?
    Answer that and you will understand the web document model, as well as the extremes of near universal interoperability possible using that model.
    Let’s examine this first from the legacy-pre Web perspective. When we open a MSOffice document, MSOffice provides the user interface. When we open a client/server application, odds are that the Microsoft desktop environment will provide the end user interface into server side systems. Indeed, Microsoft pretty much owns the ”client” in client/server.
    So what happens when you open a web application? For the most part, a browser provides the end user interface. Put aside for the moment RiA, Silverlight and direct MSOffice-Outlook to MS Web Stack alternatives, and focus on the fact that the browser is the layout engine for most web applications. How amazing is it that the web application layout engine is application independent?
    I would also argue that the browser layout engine – end user interface handles a web application ecosystem of such mind boggling galactic scale feature differentials that the laws of physics seem to have been suspended. For sure we’ve never seen this level of near universal interoperability; especially in the context of ever advancing complexity and innovation the web demands.
    Yes, you’re right. Web applications are a Tower of Babel of custom microformats and web application specific methods. Where you miss the boat though is understanding that web applications are written to either the broadest browser end user interface possible, OR, something narrow that nevertheless works within the browser interface.
    Web applications primarily write to the browser layout engine / document model. That’s why the Web works. That’s why the Web is about as close to a universal platform of access, exchange and collaborative computing as ever imagined. It’s also why today we sit at the precipice of a great divide. Microsoft web applications, services and information systems will write to a very different, entirely proprietary, layout engine / document model.
    Wikimedia, Google Docs, WordPress and Zoho Writer all share the same browser based end user interface / layout engine model, albeit leaning into different levels and combinations of HTML-CSS-DOM-JavaScript. The good news is that prominent Open Web browsers are flexible enough to handle everything from HTML 2.0 through HTML4-CSS2-JavaScript/Ajax, with a few pushing beyond to the advancing WebKit document model.
    The bad news is that the Web is going to break with Microsoft’s introduction of XAML-Silverlight-WPF technologies.
    It’s not going to break because of Adobe RiA for the simple fact that Adobe RiA implements the same WebKit layout/document model that Open Web browsers use. Did you get that? From a document format perspective, all Adobe RiA is doing is providing another end user interface compatible with other advanced Open Web layout engines.
    You seem determined to define interoperability as a clean inter-application exchange of documents based on a single document format; no customization or mapping required. IMHO, this approach demands an unrealistic similarity of web application features and services outside the arena of a common layout engine. The web document model is a much an interactive application as it is an end user interface container of content, data and media. You’re approach would strip away so much of this interactive application power that I wonder what use your brand of interop would be good for? HTML 2.0 anyone?
    Another point I would like to make is that the WebKit document model is a solid base for the conversion of powerfully complex desktop office suite documents – including the business processing layer that binds so many workgroups and client/server initiatives to MSOffice. There is no inadequacy I can see, and i’ve been working on this for some time.
    I’m not so much worried about the ”steady march of software from the desktop to the web” as I am about the great transition of MSOffice business processes to the MS WebStack – Mesh, and the conversion of MSOffice documents to XAML “fixed/flow” that transition includes. This transition represents billions of documents outside the reach of Open Web browsers and applications. It’s nothing less than a transition of the Microsoft desktop client/server monopoly to a monopoly of the business web of the future.
    I also think it is beyond ridiculous to think that web application alternatives to MSOffice will challenge this transition. The problem being that the web alternatives are outside existing business processes and are therefore destined to be as disruptive and costly unproductive as other rip out and replace efforts have proven to be in the past. Microsoft has the advantage of being able to pull off this great transition in-process. The only thing they needed was time to put together a complete client/ WebStack – Mesh /server solution, where the basic formats, protocols and interfaces remain proprietary. (a href=”http://talkback.zdnet.com/5208-10536-0.html?forumID=1&threadID=49045&messageID=916967&start=0”>The Time to Pounce Has Come)
    Reconciling Mozilla and IE layout engine requirement differentials no doubt has been a problem. A problem expressed directly in the document model mess that web applications have had to wade through. It is what it is, and there is no turning back the clock with the Web anymore than one could turn back the clock on desktop office suites and the grip Microsoft has on critical day to day business processes.
    The thing to realize is that the great transition is on. Microsoft is moving the monopoly base to a MSOffice-WebStack–Mesh footing. OOXML-XAML-Silverlight and .NET-WPF technologies overshadow in this transition all other considerations. It’s taking place right now. Whether we have one way of doing footnotes or twenty seems in context to be a mindless churn of precious wet processing units. The consequences of failing to put the Open Web in the middle of that transition are too much to bear. The W3C took themselves out of play, and I for one hope they find their way back. But there’s simply too much at stake to wait, wonder and dream of what might have been.
    So for me, the decision is easy. It’s WebKit. It’s open source. It’s cutting edge and boldly innovative. If ever there was a browser consortia capable of leading web applications forward, this is it. They religiously back-feed to the W3C, but understand what is at stake and the need to press the envelope now. And admittedly, there is a safety in numbers WebKit factor i’m comfortable with. If you’re going to run with the pack, then perhaps it’s good to find a pack with some big dogs who won’t back down, won’t tire, or be easily mislead. Like Apple, Adobe, Google, TrollTech-Nokia, Opera and now, RiM Blackberry. I’m also comfortable with the way the WHATWG group ties Mozilla to the future of WebKit.
    As a final thought, i’m convinced that both OpenOffice and MSOffice can be re purposed to produce WebKit compatible documents using existing application plug-in models. But it’s not the WYSIWYG outcome the marbux interoperability quest expects to see. IMHO, there is no sense in trying to re build these legacy layout engines. Nor can we commandeer them and force them to do something they simply are not designed to do. What we can do though is perfect an application specific round-trip mapping to and from the WebKit document model. Universal browser layout engines will have a field day with these documents, but specific web applications will need application specific mapping routines if we are to get the kind of inter-application exchange marbux interop demands.
    But hey, that can be done too!
    Hope this helps,
    ~ge~

  11. I read your article and thought, “This guy doesn’t know what he’s talking about.” Then I read @ Mozilla that if you’re not serving a web app or mathml then it’s best to use HTML 4.01.

    You’ve just blown my mind.

    I’ll probably stick with xhtml for my current site redesign that I’m almost done with, then I’ll see what the future holds for the next site I design.

    Great article. Thanks.

  12. […] Mientras esto pase les dejo una de las mejores lecturas que pude encontrar sobre este tema: Siding with HTML over XHTML. Ahí mismo pueden encontrar ligas a otras lecturas, o busquen en su buscador […]

Leave a Reply

Your email address will not be published. Required fields are marked *