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.