xhtml + CSS… #4

…true xhtml…

xhtml vs. html…

The enormous differences between HTML and XHTML will only become apparant when we want to take advantage of xml, and have to serve our documents with the proper MIME type. Time to become cautious…

MIME types

• text/html is for HTML & XHTML 1.0 mimicking HTML
• application/xhtml+xml is for XHTML, xml, Mathml and so on.

No need to go into details on that last one, as we have no idea about what can be wrapped into that xml environment in the future. It should however be obvious that HTML documents are left out, and so are all flawed XHTML documents. Once again: there is no error-recovery in XHTML.

quick test, using this page and duplicates of it:

•  ≈ HTML
•  ≈ HTML
•  = XHTML
•  ≠ XHTML
•  ⊆ xml
•  ≠ xml (this page)

Ok, so getting XHTML right can be pretty demanding if you're used to ordinary HTML and/or “tag soup” and forgiving browsers. Trying to serve “tag soup” as XHTML to xml compliant browsers is doomed to fail – no matter what we call the garbage. Yes, garbage is all we have created if browsers can't render it.

beginner-caution

It is difficult to start from scratch without the slightest bit of knowledge about web design and XHTML standards. You may save yourself from embarrassment, and the web from more garbage under false name, by designing in an HTML standard environment where minor, and even some major, errors and coding-flaws don't disqualify your first attempts completely.

Thus, a statement like XHTML is not for Beginners might be right for you. It all depends on what kind of “beginner” you are and what you wanna be in the future.

Personally I don't agree with the above statement. However, having seen some of the mess and confusion first hand, I have to admit that a pretty strong warning should be issued – before going to the next step and solve the entire problem.

knowledge first

Beginners should acquire in-depth knowledge about both HTML standard and XHTML standards before releasing anything with a doctype-declaration that spells XHTML. HTML and XHTML are two completely different “animals”, but that doesn't show when we use XHTML to mimic HTML in a HTML environment.

It is when we want XHTML to perform in an XHTML environment (xml compliant browsers) that both beginners and more advanced web designers might be caught with their pants down – literally.

If we do it right, and make sure everyone else involved also do it right – all the time, then there aren't all that many problems ahead for an ordinary “sweet little XHTML page” – or an entire site for that matter. Purebred XHTML can go where HTML has no entry, and team up with other xml based languages to perform tasks beyond most of today's web developers imagination.

XHTML is actually quite easy to learn, as long as we don't try to introduce “short-cuts” and/or sloppy code. One set of rules with room for expansion in all directions, and the rest can be discarded as rubbish until someone standardize it. Can't be much simpler than that – can it?

procedure for future-proofing…

A good and stable procedure does make all the difference. For an ordinary web page (like this one) it's all pretty basic, so I've put my own procedure for creating such pages in writing here.

1. back to the basics

   I always start out by creating a true XHTML page. I always work directly in source-code, and use Opera for preview. Others may start with Firefox or Safari, but I leave those browsers out till later.

2. I clean out all 'human errors' from my XHTML page. My tool of choice is HTMLTidy which is included in all my source-code editors.

3. Choice of doctype is important for later validation – but nothing else. I leave that to HTMLTidy, but I put restrictions on it. XHTML 1.0 has to do for now since I want to jump between MIME types – see below...

4. MIME type: application/xhtml+xml

   I serve my XHTML page as XHTML to xml compliant browsers. That's done by adding the correct XHTML extension.

   XHTML-extensions:

   • .xhtml
   • .xht

   This is how an XHTML page/document is supposed to be served to browsers. Never mind what works with other extensions, as that doesn't count at all.

5. I check appearance and performance in all xml compliant browsers at hand. I also check the information these browsers give me.

   typical and correct info:

   • MIME type from server:
     application/xhtml+xml
   • Encoding from server (used by Opera):
     utf-8 (utf-8)

   Well now. Looks like that browser got the message. Remember that similar information and performance should be expected from all xml compliant browsers, so better test until a good and stable procedure is hammered in.

6. MIME type: text/html

   I need for my web page to work in all major browsers at present time, so I “downgrade” my XHTML 1.0 page so it becomes compatible with HTML 4.01 by changing its extension. That's MIME type jumping – at least in my terminology.

   HTML-extensions:

   • .html
   • .htm

   This is where things starts to get ugly, as XHTML shouldn't really be downgraded to HTML. Well, we are allowed to do so for XHTML 1.0 only, and also must do so as long as old and xml-incapable browsers are dominating the web.

   Those who like may discuss theory and practical implications until they have reached a concensus and written a normative piece in the standards. What is important is that this page – and all others like it – can be upgraded again just by changing the extension. It is a valid XHTML page so it will survive the jump.

   Now, how many badly prepared and badly maintained web pages out here are really able to survive such MIME type jumping? Or put differently: how many web sites are future-prepared?

7. A quick check to see that the page is performing well in all browsers I care to support (that is nearly all, really), and a quick look at the infomation in my favorite browsers.

   typical and correct info:

   • MIME type from server:
     text/html
   • Encoding from server (used by Opera):
     utf-8 (utf-8)

   My XHTML page is apparently ready to enter the world of tag-soup browsers.

8. Time to debug Internet Explorer since that's the main browser that has made this MIME type jumping necessary. That debugging is all done in CSS, so my source-code is not affected at this stage.

   Microsoft Internet Explorer has no idea what XHTML is all about, but I won't let that browser destroy my carefully prepared XHTML page. If something can't be fixed in Internet Explorer because this is an XHTML page, then it won't be fixed. Haven't found any problematic issues yet.

There you are… A “sweet little XHTML page” that can jump back and forth between HTML and XHTML when called for. Now I only have to make sure it is kept perfectly valid at any stage, and HTMLTidy is called in whenever there's any doubt. Works every time and saves me from worries about the future.

Oh, and Opera sure does lend a helping hand too. Who needs validators when one can test in the real thing? Well, a round-trip to the validator now and than doesn't hurt, I guess.

As can be seen from the above, I start at the top with XHTML, and switch to the lower level of HTML later on. It is the same as when we start coding for the good browsers first, and fix things for the weak browsers later. Just a “common sense approach” in my opinion, and I always work this way.

checklist for xhtml…

It doesn't take long to check if ones creation conforms to the standards claimed in the doctype-declaration, at least on the most basic level.

1. A page with a doctype-declaration containing XHTML must work flawless in xml compliant browsers when served and recognized as application/xhtml+xml.

2. All solutions, scripts, stylesheets must work flawless in xml compliant browsers when served and recognized as application/xhtml+xml.

That's the short list, but that's also really all there is to it. We may complicate it by adding in every little detail that has to work perfect for any XHTML file to survive, but they are all parts of the above so I won't even mention them.

That one has a working creation is of course not a guarantee that the document makes sense. Semantics in web authoring – proper use of elements and so on – is still up to the individual author.

questions related to xhtml…

Those who grasped the above right away won't have that many questions at this stage. However, we all may at time like to approach an issue from different angles in order to get a better understanding of it.

1. Question: With HTML 5 slowly emerging as the next standard, is all this wrangling with XHTML really necessary?
   Answer: If you want to avoid ambiguity: yes!
   Of course: it is only necessary if one serves documents with a doctype-declaration that spells XHTML to begin with, but that's what this article is all about anyway.

   HTML 5 is one vocabulary, two serializations, and the source-code resulting from an xml serialization is in itself perfectly good HTML 5 when served as HTML. Valid and well-working XHTML 1.0 fits right in.

   In practical terms it is most often only a matter of providing a valid and well-working XHTML 1.0 document with a new doctype, which serves as a mode switch in browsers when we're serving them HTML. Although only IE needs doctype in order to perform its best, we better provide one.

   Basing ones work today on valid and well-working XHTML 1.0 Strict served as HTML has been, and still is, a safe approach. No clean-up or convertion is necessary as one goes up the conformance-ladder from one standard to the next. The familiar XHTML syntax can be used in HTML 5 no matter how it is served, and also is a requirement if one ever wants to serve documents as XHTML.

2. Question: Is the page behind this article really XHTML?
   Answer: Yes, it is. You can check it by loading its indentical twin with an .xhtml extension to the file-name. You shouldn't experience any differences in appearance in any xml compliant browser, but you sure will in Internet Explorer.

   Just to make sure you know how one little mistake may break this page in an xml compliant browser, try this almost perfect & valid example. It isn't a nice sight.

3. Question: How come the source-code behind this page looks so ugly?
   Answer: It is an old template, and has quite a few redundant elements to simplify styling in old browsers. It may look ugly now, but browsers have no problems with it.

   It won't be changed anytime soon since all the redundant elements makes it easy to include tests for both old and new browsers. “Real-world testing” is important, and I use the entire site for it.

4. Question: How can we ensure that a page is real XHTML?
   Answer: By making sure it is always kept 100% valid XHTML.

   Note that 99.9% isn't quite good enough (as you may have noticed), so we may just as well get some help from HTMLTidy during the process. Not much left for us to do when Tidy is finished – and it takes less than 2 seconds. I think it is worth it.

5. Question: But Internet Explorer and other old browsers are lost on XHTML. How do we solve that?
   Answer: By downgrading a perfectly valid XHTML 1.0 page so it becomes compatible with HTML 4.01 – that is: change its extension to .html. That ensures backwards compatibility, and is exactly how this page is made widely awailable. See the procedure above...

   There are other ways to do this downgrading, as it is all about making sure old browsers understand that the page should be handled as HTML since they don't understand anything else.

   As long as old browsers get the message that the MIME type is one they can handle, then they will handle it too – the best they can.

   Such “trickery” is necessary until all major browsers in use are xml compliant. Then we can move forward with XHTML 1.1 and XHTML 2.0 and so on. Only XHTML 1.0 may ever be served with the wrong MIME type, so leave those higher XHTML versions out for now – unless you know how to reformate the entire document on the server-side for old browsers.

6. Question: Why XHTML? Why not create pages in HTML from the start instead?
   Answer: Well, to most the choice doesn't matter at this moment in time. You may do as you please, but I advice you to learn how to develop for the future. You'll be sorry one day if you didn't.

   On this site the choice does matter – now. I want well-formed and future-prepared XHTML, and I want to keep Internet Explorer 6 in quirks mode. It's a personal preference “thing” based on experience, and you better have extremely good arguments if you want me to change my mind about it.

7. Most other answers can be found at W3C: html & xhtml FAQ.

disclaimer…

I do not claim that the road to future-prepared XHTML is without its rough stretches. There certainly are quite a few pot-holes and bumps one has to avoid. If it isn't pure and clean XHTML one wants to create, than one might be better off with old HTML where sloppy code has a chance to work.

I do claim that it is better to learn how XHTML and xml works, and practice it from the beginning, rather than to fool around with false believs and sloppy code. It is much harder to clean up ones own bad habits later on.

Take the above as the personal opinion from someone who doesn't claim to know much about web design. He does however have a background in programming on levels that make everything the web and web standards have to offer look like a walk in the park.

There's nothing to it – but a few hundred thousand browser bugs and other temporary show-stoppers. That's the fun part that makes web development look so familiar to an old machine-code programmer. I wouldn't mind if all those technical bugs disappeared for good though, as it can be enough of a challenge to deal with my own, very human, bugs.

sincerely 

Hageland 05.dec.2005
last rev: 06.dec.2008