Vertexmode.net

There is no arguing that xhtml 1.0 is a lot cleaner, easier to read, and follows logic a little better then HTML 4.01. This article will help you write your HTML like it’s XHTML coutnerpart. As an added bonus if you ever want to switch to xhtml later it will be a lot easier to make the switch. This document is currently unfinished.

Well formedness

All tags in XHTML msut be properly nested. HTML is forgiving and will render improperly nested tags. Thus the following would render in most browsers:

<strong><em>I'm improperly nested!</strong></em>

The proper way to write it in XHTML would be as follows:

<strong><em>I'm improperly nested!</em></strong>

Lowercase elements and attributes

In html you can have any variations of case inside a tag. I.E.

<ImG sRc="img.gif">

XHTML is case sensitive, and case specific, so the example above must be written in lower case:

<img src="img.gif">

Note: attribute values can be mixed case.

Non-empty elements

A non-empty element is an element with an opening and closing tag with some info in between.

 <p>This is the content within a non-empty element.</p>

In XHTML you must close all non-empty element tags. So you cannot have this:

 <p>This is the content within a non-empty element.

In HTML 4.01 empty tags consist of <meta>, <link>,<hr>, and <img>. You must close all other tags.

Quotes around attribute values.

In HTML you do not have to put quotations around attribute values. So the following will render just fine despite the mismatched use and disuse of quote around values.

 <table border=0 width="90%" cellpadding=10 cellspacing="10">

If you want to conform to XHTML you need to put quotes around all your values like the following.

 <table border="0" width="90%" cellpadding="10" cellspacing="10">

I try to be impartial, but I’m only human, so I guess you’ll have to take this as just my opinion. That being said I will do my best to provide the facts, and from that fact hopefully you can come to a decision as to what you truly want to use. This is obviously geared towards beginners as anyone with any experience is well aware of these issues. This is mainly intended for users who are completely new to website creation and who probably don’t understand the issues surrounding (x)html. Before we start I’d like to point out this article written by Loren Wolsiffer that you’ll probably want to read after this. (It’s not written very well and you may not understand a lot of what he’s talking about until after you read this)

Value of XHTML

Benefits of XHTML

1. XHTML must be valid code.
2. XHTML must be well formed xml.
3. XHTML throws catastrophic errors when it encounters invalid code.
4. XHTML can use alternate xml namespaces.
5. XHTML makes DOM scripting easier.
6. XHTML can have xml tools used on it for content management.

Downsides of XHTML

1. XHTML doesn’t work in IE AT ALL if served as xhtml.
2. XHTML doesn’t display until fully downloaded in mozilla browsers.
3. XHTML confers no practical value if served as text/html.
4. XHTML doesn’t allow document.write() javascript. (Which is viewed in a positive light by some)
5. Inline scripting and CSS are broken unless you use extremely long escape sequences (not an issue as you should have that all modularized anyways). Inline scripts/css are stored in the html document rather then a .css or .js file.

More markup issues

Value of HTML

Benefits of HTML

1. HTML 5 is in development by WHATWG . (no longer a dead language)

Downsides of HTML

1. None.

Facts on XHTML and HTML

Fact 1 – XHTML is properly served as application/html + xml.

application/html + xml is a mime type the web server passes the browser in the http header. A mime type simply describes to the browser what type of file it’s getting so it can decide what to do with that file. It is nothing you can control inside the document itself. If passed application/html + xml, you don’t even need to state a DOCTYPE as the browser automatically assumes XHTML 1.0 strict. That being said, if you don’t have access to the web server(or server side script), you cannot change the content type. If the server can’t serve application/html + xml, you can’t get any of the “practical” benefits from XHTML.

As an aside: The one other practical benefit of XHTML is the use of xml tools with the document such as a Content Management System.

Fact 2 – XHTML is only “practically” beneficial when served as application/html + xml.

Yes I agree that XHTML is theoretically beneficial to practicing good coding techniques, but I disagree that html is not also helpful in that regard. Many argue that XHTML forces proper coding techniques such as lowercase element names, enclosing values in apostrophes, and using proper closing tags. However, you can still do that in html 4.01, even though you don’t have to.

It’s also argued that XHTML is theoretically beneficial in “future-proofing” their document. But that theory is also flawed as now both XHTML and HTML 5 are in development.

The only way to get the proper xml rendering and error checking for XHTML is to serve it as application/html + xml. Without declaring that mime type, what you are serving is invalid HTML 4.01.

Fact 3 – XHTML served as text/html is invalid HTML 4.01

“Current UAs (Browsers) are HTML user agents (at best) and certainly not XHTML user agents (certainly not when sent as text/html), so if you send them XHTML you are sending them content in a language which is not native to them, and relying on their error handling.” – Ian Hickson

XHTML is designed to be served with the mime type application/html + xml, and when not, is passed as text/html. The browser can make it work due to an SGML parsing bug. So I guess if it works more power to you but it doesn’t make it proper. So, yes an XHTML document may be well formed, and yes it may validate, but the browser thinks it’s html, forcing the browser to guess at what you mean.

Fact 4 – XHTML served with application/html + xml content type is unsupported in ie7 and older.

This is the killer for me, I would be using XHTML right now on my personal sites right now if it weren’t for this. Quite possibly on my commercial sites as well, but we use third party software on some of them which would make conversion and upkeep a pain.

When you send XHTML with the content header of application/html + xml, IE renders an xml tree. Not only that, but IE7 doesn’t support the application/xhtml + xml mime type. As of this writing it does not appear that IE8 will have xhtml support. At this time I’m not certain I’d get my hopes up that IE will ever support xhtml. With no IE support you can’t reliably use XHTML unless you don’t care about serving to IE users.

Fact 5 – HTML is always supported.

HTML is going to be around for a good while longer, a lot longer then any of us had probably anticipated 5 years ago. It’s supported in all mobile devices, and it’s unlikely the devices will ever leave the SGML parser and go to a strictly XML one. In addition the WHAT WG is in development of (X)HTML 5.

Fact 6 – <?xml version=”1.0″ encoding=”UTF-8″?> Triggers quirks mode in IE6.

You don’t want quirks mode, ever. XHTML is meant to be strict, and if you’re triggering quirks mode you’re implenting counterproductive practices. Quirks mode was designed so browsers could handle documents that haven’t been accurately described with a doctype. Many elements are displayed differently in quirks then in standard mode and you will create some issues with css.

What does all this Mean?

Choose the option that works for your project.

Ultimately choosing a doctype is personal preference, as you’re going to create in whatever environment you’re comfortable in. This article is intended to instruct that you shouldn’t just copy an XHTML doctype (or any doctype for that matter), or add an XHTML doctype without understanding the implications.

What should you choose?

It’s all dependent on the project, and that’s what should matter most. For most beginners HTML 4.01 will probably suffice for anything you’d need to do, and when it validates you’ll know that in _most_ environments it’ll render correctly.

If you want to use MathML or SVG and don’t care about IE users then by all means use XHTML served as application/html + xml.

If you enjoy learning to conform to the strict coding practices of XHTML and serve as text/html, then by all means go ahead, but keep in mind that if you ever try to serve it later as application/html + xml that it probably break HORRIBLY.

What would I choose?

Bias?

I would choose HTML 4.01 for anything not requiring MathML, SVG or XML content tools. I know HTML and I write it as close to XHTML as possible. In my opinion the negatives of XHTML far outweigh the benefits. Sure I loathe MS as much as the next person, but I’m not going to abandon what could possibly be 80% of my users. I also would be afraid to use proper XHTML in the workplace as I probably won’t be employed there for ever, and when someone else could start adding content to the site it wouldn’t take much to completely break the site.

I’ve added an xhtml playground, and to view the site you need a proper browser. (Safari, Firefox, Opera, or Konqueror) Ie6-7 cannot interpret the xhtml mime type and you get a download prompt. So get a real browser and lets try to finally move to xhtml. Even though we’re about 5 years behind schedule on that one, with about another 5 years to go!

The section is currently fairly lame as I’ve just been busy trying to get it to work (damn remote hosting) and have just a test document up at the moment. Later I intended to play around fully with SVG. Although I am upset with my current tests however, as the SVG support in Firefox seems rather limited. Either way, keep on the lookout for that.

I also modified a page for a co-worker, as she was redesigning her portfolio and was trying to use tables for layout, so I made this CSS2 layout for her. If you have time stop by and check out some of her work, it’s pretty good (maybe that’s because some if it’s my work too? ;P)

Two new articles up in the tutorials section, both aimed at beginners; “How to write HTML like XHTML” and “How to decide on XHTML or HTML”. For the latter article I tried to take an impartial side to the debate, but that’s only so possible as XHTML has some major flaws that have to be addressed.

In other news I took out the ajax (was keeping adsense from display ads relevent to the content, plus I had no meaningful meta content for each page) So now I’m using php to generate a header and footer, and slap the content in the middle. Next I’ll be writing a function that can be called from the content page to pass meta values to the header page. In addition I think I’m going to write a “contact” page so I can get my email off the page header. I would prefer not to be gettin junk mail at my main email.

Last up for current articles will be a learn html article, as it’s hard to find any reliable articles out there that stress form.

I’ve decided that with my new interest in this site and web standards I’d write an article based on web standards for the beginner. A simplified version of the xhtml vs. html argument , doc types, and writing valid code. Which should become available in the coming weeks.

The topic has required a lot of reasearch on the subject, which was necessary based on all the unfounded arguments floating around ont he web. Not to mention just a general misunderstanding of xhtml and html. It seems as if neither side really understands the other (akin to a generational gap between a grandparent and their grandchild) to the point where they will make wild assumptions about the other markup langauge.

I have reduced some of the functionality of the ajax script before I end up removing it all together. I’ll paste it here so that you can see it in it’s entirety if I do completely remove it. The httprequest object creation is based off the script I found at w3schools.

function createAjax() {
  var xmlHttp;
  if (window.XMLHttpRequest) {
    xmlHttp=new XMLHttpRequest();
  }
  else if(window.ActiveXObject) {
    try {
      xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
    }
    catch (e) {
      try {
        xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
      }
      catch (e) {
        alert("Your browser does not support AJAX!");
        return false;
      }
    }
  }
  return xmlHttp;
}

function getType(name) {
  xmlHttp=createAjax();
  xmlHttp.onreadystatechange=function() {
    if(xmlHttp.readyState==4) {
      document.getElementById("content").innerHTML=xmlHttp.responseText;
    }
  }
  xmlHttp.open("GET",name + ".html",true);
  xmlHttp.send(null);
}

Quite simply I call getType() with an onClick() event on one of my links, passing it the content type I want. I.E. if I want about.html, I just call getType(’about’). Then an HttpRequest is created, and the responses is placed inside my content div tag.

I eventually plan on removing this completely, but will instead start using it for comment areas on my articles (or whatever else I feel needs it). This initial implementation was simply a demonstration for myself and my friends. I was also interested in how standards compliant it was. That’s about all for now, so until later.

I’m at a record pace this week, with two whole posts. The reason of this post is I added some superflous technology to the site and wanted to share with you. I’ve been reading up on AJAX lately and implemented it in my site. If you don’t know what AJAX is, you will notice when you click on any of the links to the left that lead you to a page that looks like this one, the whole page doesn’t refresh, only the content area does. AJAX allows you to make http requests without reloading the page (which is pretty handy.) One good example of this is the events calender webiste onCurrent. Their nav and content are seperated so you only have to reload the important part of the page.

Now my site is entirely too small for bandwith to really be a concern and I don’t have any dynamic content, so it’s really not nessecary. However, I still wanted to implement it in site, and it does allow me to seperate the rest of my page from all it’s content. I.e. I can update the header or the navBar in one page and it’ll show up on every page thereafter, as opposed to having to make the change on every single page.

This method does have it’s drawbacks though. If a user has javascript disabled they cannot veiw my site. I will have to find a way to send users with javascript turned off to a page where it’s not used. Again that may not be necessary as I’m fairly certain my user-base will all have javascript enabled. But as a saftey measure I think I’ll add a warning.

It’s a fairly simple bit of code if you get it from my scripts directory you can see. I guess the next improvement is to be some dynamic pages, I’m assuming a comments page. So I can at least get some use out of this technology. That’s all for now.