The risk of using XHTML correctly and the solution

Xhtml| solved my use of XHTML for some years, but until last summer I looked at how to use it correctly, that is to say, to application/xhtml+xml MIME type to servo (server) it. I know I have some problems, but the problem is far from the same. As you're about to discover, when you start using real XHTML, you get a lot of seemingly small but confusing questions.

Please note that this is not a discussion article that supports or opposes the use of XHTML. I just write down the potential mistakes I know and let you decide for yourself: HTML 4.01, XHTML 1.0 for all browsers, or text/html for browsers that can handle it application/xhtml+ XML while the other browsers are servo-text/html XHTML 1.0. Otherwise some things will be completely different.

Whenever I encounter the occasion of their occurrence, I begin to understand one question after another. In some cases I have to spend a lot of time looking for problems and turn to others before finding a solution. But I've learned a lot from it, and I'm going to tell you what I should know after I've used XHTML.

Note that the problem I mentioned here only occurs in user proxies that can handle application/xhtml+xml MIME types correctly, and therefore XHTML is used as XML. This may also be the reason why the early use of XHTML is not mentioned here--few people use such browsers, so almost no one is upset by the text/html XHTML.

Today, the fact that XHTML Servo is application/xhtml+xml is slowly becoming commonplace. There are two reasons I know:

1. Use Firefox,mozilla,opera. The number of safari and other XHTML-compliant browsers has increased, so you're no longer just doing this for yourself and your partner. Well. Maybe you do that when it will affect more people.
2. Among web developers, there is a growing awareness of what the true nature of XHTML is. There have been a lot of heated discussions about using XHTML, especially when Servo is text/html. If you're involved in any discussion, you know what I'm talking about.

If you, like me, decide to implement certain types of content negotiation and use the right media type when delivering XHTML, you need to know what can (and will) happen in your published documents and how to avoid the problem. For readers who are interested in the content negotiation with the content negotiation, I recommend that you read content negotiation and serving up XHTML with the correct MIME type (this site has an earlier translation: Use the correct MIME type servo XHTML). There are many of these types of articles, but this is the most wonderful two I have read.

Each basic tutorial has a clear distinction between HTML and XHTML: element and attribute names use lowercase, and property values are always quoted. Do not use simplified attributes to ensure that all elements have an end tag and no incorrect nesting, and so on. However, there is more to be learned when XHTML Servo is application/xhtml+xml.
Good structure is necessary.

The document must be well-formed (well-formed) XML (not necessarily the same as legitimate (valid) XHTML). There is no compromise on mistakes, no chance. If the document is poorly framed, standard browsers (currently I know Mozilla,firefox,netscape,camino,opera,safari and omniweb-- Quite a few browsers, except IE, will display an error message and, in some way or another, abort the processing of the document.

In addition, this also means that the "&" number is no longer encoded.
The XML declaration may be required

If you want to use a character encoding other than UTF-8 or UTF-16, the XML declaration is required unless the HTTP header already provides the encoding.

Do you want to specify that the character encoding is somewhat blurry in the HTTP header, architecture of the World Wide Web, Volume one:media Types for XML so stated

Overall, you should not specify the character encoding for the XML data in the protocol header because the data itself is described.

On the other hand, XHTML 1.0, Second edition:character encoding said:

The best way to get the document to use the specified character encoding is to ensure that the Web server sends the correct headers.

That is, it is a good practice to specify a character encoding in an XML declaration:

<?xml version= "1.0" encoding= "UTF-8"?>
Only five entities are safe.

Support for only five predefined entities (<, >, &, "and") is guaranteed. Others may be completely ignored or directly output. For example, if the XHTML document contains an entity such as or, Safari will generate. directly. Instead, opera chooses to ignore unknown entities, while the Mozila family recognizes these entities and processes them in HTML "if documents refer to identifiers in the common mapped browser pseudo DTD directory and do not have a separate declaration document."

Using UTF-8 character encoding is a highly recommended practice that allows you (almost) to use any character you need to type a document without an entity or character number. If you are unable or unwilling to use UTF-8, numeric character numbers can be supported and safely used.
The contents of an SGML annotation may be ignored

SGML Comments (HTML style annotations, <!--annotation-->) may be (and will) be commented by the browser, even within the script or style element.

In HTML, the contents of Sript and style blocks are generally loaded into annotations in order to hide them in browsers that do not know the script or style elements, and to generate plain text on the page.

In XHTML, doing so causes the browser to ignore any content in the annotation.

The practice of hiding script and style elements in old browsers is a habit of returning to the middle of the 1990. My experience is that browsers with such performance are very rare, so you can safely ignore them and stop the SGML annotations in scripts and styles, even if you're using HTML.
The contents of scripts and style elements are also treated as XML

The style and script elements are pcdata (parsed character data, parsing character datasets) blocks, not CDATA (character data, character data) blocks. So anything that looks like XML in it is parsed as XML and can cause errors unless it is well-formed.

To use <, &, or--in Stylee or script blocks, you need to use a CDATA section to wrap the content:

1. <script type= "Text/javascript" >
2. <! [cdata[
3...
4.]]>
5. </script>

In the CDATA section, you can have any sequence of characters that will not be parsed as XML (except to end CDATA Part]]>.) ）

In documents that need to be sent as text/html, the start and end tags of the CDATA section need to be commented out to hide in browsers that cannot handle CDATA sections:

1. <script type= "Text/javascript" >
2.//<! [cdata[
3...
4.//]]>
5. </script>

1. <style type= "Text/css" >
2./* <! [cdata[* *
3...
4./*]]> * *
5. </style>

If you want to make sure that the old browser hides the CDATA section, you need to use a more sophisticated approach, as described in Ian Hickson's sending XHTML as text/html considered harmful:

1. <script type= "Text/javascript" >
2. <!--//--><! [cdata[//><!--
3...
4.//--><!]] >
5. </script>

1. <style type= "Text/css" >
2. <!--/*--><! [cdata[/*><!--* *
3...
4./*]]>*/-->
5. </style>

A better approach might be to use the content negotiation script to remove any CDATA portions before sending a text/html document.

Of course, the smartest and safest way to do that is to move all of the CSS and JavaScript to an external file, but not always the real thing.
No elements that will automatically complement

In HTML, if the TBODY element of the table is omitted, the browser is automatically filled, and XHTML does not. If you do not add tbody clearly, it will not appear. Keep in mind when writing CSS selectors and JavaScript.
Scripts written with document.write no longer work

Using Javascript,document.write in XHTML does not work. Ian Hickson explains why why document.write () doesn ' t work in XML (this site has long been translated: Why document.write does not work in XML). You need to use Document.createelementns () instead. Find out more about the forum topics that are available in experts Exchange.

This is one of the reasons Google AdSense does not work in XHTML. For those who want to use Application/xhtml+xml servo XHTML and Google ads, here's a solution: Simon Jessey's making AdSense work with XHTML (this site has an early translation: so that Google advertising adsense in the XHTML work). Although a bit of trouble, but still work (I also used here), at the same time by Google's endorsement.
Introducing Style elements

In XHTML, in order to be compatible with XML methods that define CSS rules, you should use XML stylesheet declarations (access to XHTML 1.0, Second edition:referencing Style Elements when serving as XML XML-like Table declarations and associating style Sheets with XML documents xml-stylesheet processing instructions). To load an external CSS file, we need to use the style element, and we should use an XML stylesheet declaration to introduce the style element. To do this, use the id attribute to give the style element a decomposed identifier, and then introduce the identifier in an XML stylesheet declaration:

1. <?xml-stylesheet href= "Stylesheet1.css" type= "Text/css"?>
2. <?xml-stylesheet href= "#stylesheet2" type= "Text/css"?>
3. <! DOCTYPE html
4. Public "-//W3C//DTD XHTML 1.0 strict//en"
5. "Http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd" >
6. 7. 8. <title>xml Stylesheet declaration</title>
9. <style type= "Text/css" id= "Stylesheet2" >
@import "Stylesheet2.css";
One. </style>

I don't know how necessary it is in practice to have a problem with an XML stylesheet declaration. Maybe someone will enlighten me.
CSS application rules are somewhat different.

CSS applied to the nature of the body does not apply to the entire document of XHTML. The most noteworthy is the application background color or picture. In HTML, the background applied to the BODY element will overwrite the entire page. In XHTML, you have to format HTML at the same time. This behavior is demonstrated in Juicy Studio's CSS body Element test.

Element and attribute names in XHTML as CSS rules are case sensitive (and must be lowercase). The easiest way to avoid a problem is to keep everything lowercase in both html,xhtml and CSS.
It's a challenge, but it's not impossible.

When I started hosting XHTML for compatible browsers for Application/xhtml+xml, I might have a lot less headaches if I could read the same article before making a decision. I even consider using HTML 4.01 Strict. Even so, I learned a lot from experience, and learning is always a good thing.

Using true XHTML correctly, hopefully this article will provide you with some more useful information and can provide more of a basis for deciding whether or not to take this route.

HTML and XHTML may be more different than what I mentioned here, so here's what you encounter when you use Application/xhtml+xml xhtml, and if you know any errors or ignore them, be sure to tell me.