This is our seventh and last post on XHTML/HTML.  With this post we want to draw some conclusions with regards to all the information that was provided.

HTML and XHTML offer very similar functionality in terms of describing and marking up documents for the web.  XHTML has a number of advantages in terms of its interoperability with other markup documents, and its consistent syntax.

A few years ago, it seemed clear that XHTML would be the “future of the web”, but more recently, HTML has grown in popularity, as browser support for XHTML has often not kept pace with developments. The competition on who is going to be more popular is still open. even if we believe XHTML has some definite advantages.

But if you’re ready to make the transition from HTML to XHTML, you’ll want to check out Aggiorno – a plug-in for Microsoft Visual Studio that has embedded knowledge about the differences between HTML and XHTML – to make your transition easier.  It automatically targets XHTML 1.0 Transitional documents and makes sure your pages are error-free and up-to-date before going on to offer additional improvements, such as improving accessibility, automatically upgrading table layouts to use CSS and extracting master pages from sites with similar formatting.

This is the sixth installment of our XHTML/HTML series. So now for the bad news.  In addition to the syntactic differences, HTML and XHTML do not share the exact same semantics, and there are things you should watch out for.  In particular, HTML assumes that it is rendering to a browser, and “takes over” the browser window.  The XHTML model is to assume that it is rendering to a specific target area.  The consequence is that CSS styling (for example, backgrounds) for XHTML applies generally only to the area where there is content, while for HTML, the background applies to the entire window.

At the same time, there are differences in parsing the XHTML file.  Because XHTML is first and foremost an XML document, it is generally processed as such before any of the content is considered.  This has two significant consequences.  Firstly, anything placed within a comment block is likely to be completely ignored, as comments will be thrown away during parsing.  Since comments are often used in HTML to “hide” unwanted items such as stylesheets and JavaScript documents, this can have serious consequences.  Secondly, those same elements will be “parsed” by the XHTML parser if they are not within comment blocks, and that may lead to parsing errors.  Since it is a requirement of all XHTML documents that they be well-formed XML documents, or they will be rejected by the browser, any such problems will cause the whole page to be rejected.  To solve this problem, it is necessary to place stylesheets and JavaScript within CDATA sections in your XHTML file.

There are a number of other inconsistencies relating to the functioning of JavaScript within XHTML, for example document.write() does not work in the same way, since the document has been fully parsed by the time the call is made: instead, it is necessary to directly manipulate the DOM of the page.

In summary, XHTML has a more strict format that can be checked by development tools and can be fixed before it is sent out to a browser. HTML is a bit more forgiving. Browsers accept ill-formed HTML. This is a good thing from the perspective of tolerance with programmers mistake, but it is a bad thing as browser interpret the ill-formed code in different ways.

This is the fifth installment of our XHTML/HTML series. Extending the notion of using other, W3C-approved XML, extension languages along with XHTML is the idea of completely replacing the XHTML content with simpler XML content.  Domain Specific Languages (http://en.wikipedia.org/wiki/Domain_Specific_Language) are generally computer languages which have been specifically designed with solving problems in a specific domain.  The notion is that frequently-expressed concepts work their way into the statement of the problem, rather than being expressed in the solution to the problem.

The same approach can be used with XHTML.  Because it is possible to use a stylesheet to transform any tree within an XML document, and because so much of what makes a web page is boilerplate, it is possible to extract the boilerplate into a stylesheet and then use that to define a domain-specific language.

A Simple Example

A simple example should suffice to demonstrate this approach. Imagine that you are running a bookstore, and you have information about your books stored in XML somewhat as follows:

<book>

      <title>Arthur's Tree House</title>

      <author>Marc Brown</author>

      <coverImage>8037.jpg</coverImage>

      <price currency=”USD”>399</price>

</book>

By simply adding the following two lines to the top of this file (and providing all the referenced stylesheet information), you can automatically transform this into a complete XHTML page:

 

<?xml version="1.0" encoding="utf-8"?>

<?xml-stylesheet type="text/xsl" href="BookClub.xslt"?>

This works because the browser knows when downloading an XML document with the xml-stylesheet processing instruction to automatically apply the specified stylesheet before attempting to display the page.  The stylesheet generates XHTML output, which the rendering engine knows how to display in the browser.  The CSS styling (attached within the XSL stylesheet), provides the style, completely separated from the content.

Did I lose you?

Apologies if that didn’t seem as simple as the title suggested.  The principle is that creating the content pages should be simple – because much of the complexity has been sucked up into the XSL stylesheet.  And the mechanism for triggering this – identifying the stylesheet within the file – is also simple.

Writing XSL transformations themselves, however, is not so simple.  But it does hold great advantages when you have truly domain-specific information, as in this case, which you might want to use in numerous different ways in a single site.  For example, you might want to display books in each of the following contexts:

• On their own page, where all the information about the book is shown;
• On a recommendations page, with just the cover and the title;
• In a list (such as the shopping cart) without the cover image.

And in each context, exactly the same XML file could be used, but with a different XSL stylesheet on the page to make a different transformation to different XHTML.

In Summary

The power of XML, specifically with regard to XSL stylesheets, can be leveraged within XHTML to reduce the complexity of making individual documents and to promote reuse.  The value of this technique depends on the other elements that collaborate to form your complete system.

This is the third installment of a series of blog posts to discuss HTML, XML and XHTML.  

A major difference between HTML and XHTML is the manner in which they are interpreted by the browsers.  HTML and the browsers having grown up together, browsers tend to be very tolerant of poorly written or outdated HTML constructs.  XHTML, on the other hand, is treated very strictly by browsers.

How serious are you about Web standards?

Although it’s just as possible to write high quality HTML as it is to write high quality XHTML, it can be harder to know that you’ve written high quality HTML.  Because the browsers “gloss over” many of the problems in HTML code, it often seems that what you’ve written is good HTML.  With XHTML this is not the case – browsers reject invalid XHTML without question.

Getting Help to Get There

Of course, in either HTML or XHTML there are tools that can help you.  The W3C validator (http://validator.w3.org/) will check any of the six possible schemas of HTML or XHTML.  Microsoft’s Visual Studio environment will include warning messages about invalid usages of your selected schema.  And Aggiorno (http://www.aggiorno.com) will not only check your documents, it will automatically fix structural and deprecation problems and bring your files up to full XHTML 1.0 compliance.

In Summary

XHTML offers stronger compliance rules with browsers than HTML, along with better tool availability for enforcing that compliance.

This is the second installment of a series of blog posts to discuss HTML, XML and XHTML.  An often asked question is “What are the differences between HTML and XHTML?”  But actually, a much more interesting question is “What do HTML and XHTML have in common?”

It’s all about the content

HTML and XHTML are both content markup languages.  That is, in both cases, the most important thing is that they are describing some content being used for communication.  The content is marked up so that computer software – especially browsers – can determine the significance of the content and render it appropriately.

HTML and XHTML have the same rules about content, and the same markup constructions.  Because of its history, HTML allows some outdated markup to be accepted which XHTML does not.

They delegate styling to CSS

Both HTML and XHMTL delegate the styling of pages to CSS.  The same CSS.  There isn’t one CSS for HTML and another for XHTML, although a few of the rules are interpreted slightly differently in the two cases.

They are W3C standards

Both HTML and XHTML are technical recommendations from the W3C – so called “Web Standards”.  Theoretically, any valid HTML or XHTML document should be accepted by all “user agents” out there – from browsers and screen readers to search engine bots.

They have similar appearance

Both HTML and XHTML use SGML as a reference base, and as such, they look very similar, especially when you consider that the valid markup tags in the two languages are the same.  There are superficial syntactic differences, particularly in terms of HTML’s tolerance for tags in different cases, and XHTML’s stricter rules on closing tags.

In Summary

HTML and XHTML are very similar in purpose, intent, layout and appearance.  XHTML has a more consistent syntax, while HTML can be shorter and is more tolerant.

This is the first installment of a series of blog posts to discuss HTML, XML and XHTML, what they are and why more and more people are moving from HTML to XHTML when producing web content.

This first article looks at the history of these markup languages.

In the beginning…

HTML and the Web have grown up together. Originally, HTML was a simple markup language defined using SGML, which was intended for the creation of documents that referenced each other. Using hyperlinks, these references could be easily followed, rather than needing to go back to the catalogs to search for the referenced articles.

As the Web grew in reach and popularity, more and more functions (such as fonts, tables, forms) were added to HTML by the browser manufacturers working in competition, delivering exciting new features that only worked on one browser. Designing web sites became more challenging, more fun and more frustrating at the same time.

Then came the standards…

As time moved on, it became clear that this way of working was hindering, rather than helping, the development of the web. The W3C decided to increase its involvement, and its HTML 4 and CSS 1 “recommendations” became the first standards to lead, rather than follow the technology.

Defining a clear and clean “standard” way of expressing documents, these two standards are the core of what HTML content on the Web should be today. Unfortunately, the browsers have generally failed to fully adopt the W3C’s recommendations.

Then came XML…

HTML is an SGML application, specific to the generation of web page content. While this can be used to describe “anything” to other people, the document structure stops it being more immediately comprehensible to machines. The markup only enables browsers to understand the relative significance of the different pieces of text; it does not allow the creation of more complex structures, for example to describe all the properties of different food products, such as nutrition information.

XML was created to allow the definition of computer-comprehensible descriptions of artifacts. Using HTML’s heritage from SGML, XML appears superficially similar. But while the rules of HTML define the exact vocabulary of concepts that can be conveyed, XML was designed to be extensible: that is, the set of concepts which can be directly conveyed – through computer-comprehensible markup – is unlimited. As XML evolved, interoperable schemas were introduced, which allowed a single XML document to incorporate multiple distinct content types, all machine-readable, all machine-verifiable.

And XHTML …

With XML came the notion of XML languages to describe different types of content. One of the first to be adopted was the definition of hypertext documents – XHTML. With the same semantic description as HTML, XHTML documents appear similar to their HTML relatives, but nevertheless carry some key advantages.

Making the Switch

It’s generally considered relatively easy to switch from HTML to XHTML, since the differences are largely syntactic, although some issues are bigger than that.  But making all those changes, particularly the ones that are completely incompatible, can be a pain.

Using Aggiorno

Aggiorno is a software product that can rapidly assist in making the switch from HTML to XHTML by automatically applying all the right changes for you.  Working from within the Visual Studio environment, one action can operate on multiple legacy files at the same time, fixing errors and removing outdated constructs while converting everything to the latest Web Standard XHTML.