The dilemma arising from MIME Type

Mime everything starts with a bad browser and it doesn't support XHTML at all.

　　 What is MIME Type?

Why do you say that? First, we need to understand how the browser handles content. The content displayed in the browser is HTML, XML, GIF, and Flash ... So, how do browsers differentiate between them, and what is the absolute content to display in what form? The answer is the MIME type, which is the media type of the resource.

The media type is typically through the HTTP protocol, which is communicated by the WEB server to the browser, or, more precisely, by means Content-Type of, for example:

Content-Type: text/html

Indicates that the content is a text/html type, which is a hypertext file. Why is it " text/html ", not "" html/text or something? The MIME type is not specified by the individual, and is published online as an RFC, as recommended by the IETF organization, and most WEB servers and user agents support this specification (by the way, the type of the Email attachment is also specified by the MIME type).

Usually only a few formats that have been widely applied on the internet will get a MIME Type, and if it is a format that is defined by a client itself, it can generally only application/x- begin with.

XHTML is a widely used format, so in RFC 3236 , the MIME Type of the XHTML format file should be application/xhtml+xml .

Of course, with a local file, the browser does some default processing when no one tells the browser the MIME type of a file, which may be related to the MIME type you configured for the file in the operating system. For example, under Windows, open the Registry's HKEY_LOCAL_MACHINESOFTWAREClassesMIMEDatabaseContent Type primary key, and you can see the configuration information for all MIME Type.

　　 What is the difference between the browser processing XHTML and HTML?

HTML syntax is too random, there are many shorthand, tag mismatch of the complex, while the long-term WEB development has accumulated a lot of wrong usage-such as a document is completely unmarked-but browsers still have to support it, it is conceivable, in order to support these "tag Soup"- That's what we're talking about, porridge tags--browsers have to struggle to guess the meaning of a mark and try to express it in the form of a user's expectation. In other words, although HTML 4.01 allows you to write tags in a semantic, structured, content-and-performance-separated way, because it follows the HTML format, the browser text/html has to take a very laborious approach to any file with MIME Type "" /c6>, this is bad for the development of the WEB.

Besides the browser, there are many other user agents to read HTML: Plain text browsing tools, screen readers and so on.

　　a large part of the reason for creating XHTML is to redefine the markup again through XML, allowing these user agents to parse the tags in a simpler way. Thus, the new format of XHTML, by nature, requires publishers of content to label their documents in strict ways.

Of course, XHTML is also good for content providers, not to start here, as described below.

　　 What does MIME Type have to do with it?

By combining the contents of the first two sections, you can clearly see that a properly supported XHTML browser will distinguish between HTML and XHTML based on the MIME Type provided by the server, and text/html application/xhtml+xml two different ways to parse the document. is much more rigorous, but it is good for both user-agent developers and content providers.

So, do those browsers normally support XHTML? The answer is Mozilla, Mozilla based browsers such as Netscape 7 and Firefox, newer versions of Opera and Safari, and so on. It does not include Microsoft Internet Explorer. Problem is, this "does not include", the elimination of about 90% of the browser market ah, before we go crazy, to see what IE is handled application/xhtml+xml : IE does not recognize this MIME Type, it will either prompt you to download the file, or the contents of the file as plain text display, No, it's not possible. O-Tolerance neck tan cha?/p>

That's why we had to label the XHTML document text/html 1, and in fact, 95% of XHTML on the Web today is XHTML (including w3.org), browser (including our proudest Mozi LLA) did not parse the XHTML with an XML parser, but rather used the old-fashioned way of handling tag soup.

At this time you will ask, in my eyes, the old way is very good, why do you feel a headache? The problem is in the word "look", in fact, some subtle but not negligible differences still exist.

　　 application/xhtml+xml how text/html to parse the differences between XHTML and using methods

The following "HTML" means text/html the parsing method, and the corresponding "XHTML" means " application/xhtml+xml ".

1. This is the most important, strict XML parsing requires at least the document is well-formed, that is, the tag should be properly closed, & such as XML entities to use correctly.
2. In HTML is the user can see all the view, to set the body background color is to the entire document set the background color, but not in XHTML, to set the background color effect and to set the difference.
3. In HTML, the matching of elements in CSS rules is case insensitive, the body and body match the same element, but in XHTML it is case sensitive.
4. JavaScript scripts that are hidden in comments are ignored by XHTML.
5. document.write()cannot be used in XHTML.
6. The element and attribute return values for HTML DOM and XHTML Dom are different, uppercase in HTML, and lowercase in XHTML.
7. There are a number of other DOM problems.

To sum up, what we are widely using is actually a seemingly XHTML HTML, imagine if all these sites are required to replace MIME Type immediately application/xhtml+xml , even with browsers that can parse XHTML normally, Most of them will die in the previous list of reasons, cannot be displayed correctly. This is not an XHTML error, however, and normal processing is supposed to be the case, but we have been tolerated.

But the consortium is constantly asking us to provide XHTML with the correct MIME Type, why? Because we want to use XHTML to provide the benefits , only the browser is considered to be XHTML or XML documents, browsers will enable these "benefits", such as you can try to open in IE in XHTML embedded in the MathML look, no effect, it is used as HTML as shown.

The question now is, since it's such a hassle to set up a document as true XHTML, there are so many problems, why not stay comfortable in HTML? Why transition to XHTML? is the "benefit" provided by XHTML worth so much to pay for?

　　 the advantages of XHTML

The most important two points are:

1. In addition to the easy handling of the user proxies discussed earlier, in fact, a large number of xml-based tools, many of which are well supported by XML, can easily parse your documents and extract the information you need. Of course, also include search engines.
2. You can use XHTML to inherit good extensibility from XML, such as embedding RDF data in XHTML, describing the semantic information of documents, adding MathML tags, describing mathematical formulas, adding SVG tags, and using scalable vector graphics.

Obviously, if the document does not even well-formed, the advantage of 1 is not valid for you, even if it works, personally, there are not many people in the XML parsing of XHTML, because can do, probably from h1 , h2 These tags read out the structure of a document a class of functions, It's not very useful.

and 2nd for most content providers, too far away, what is RDF? What are the benefits of adding RDF information? Not many people know or are interested to know; MathML? This is where scalability is currently used most, because many MathML reading and editing tools have become commonplace, but if you're not a science worker who spends a lot of time in formulas, it's probably not interested in it. It's interesting, but it's obviously not getting a wide range of applications, and in fact, whether it's going to get a wide range of applications in the future depends on how it can survive the competition with Flash: It's also common to be abandoned as a standard thing.

summed up, all of these advantages are almost some of the bad checks, some future can be realized even the future do not know what can be achieved, for example, you are now developing a CMS system, if now are not guaranteed inside the content well-formed, what reason to say later, the data more and more later, Instead of going back and correcting the wrong marks?

　　In fact, our lives have been almost unaffected by the lack of these checks.

So, does that mean that XHTML is almost a chicken?

　　 XHTML, XHTML.

In this case, I have been deadlocked, in fact, I did not intend to make XHTML so bad, but the problem is that every sentence I say is true, and there is no need to ignore what is necessary to mention the factors, but repeatedly examined, summed up or that sentence:XHTML is actually a little idealistic, for ordinary users , compared to HTML 4.01, there is no obvious advantage in the format.

So we are in a dilemma: to dig out those rhetoric, without any obvious advantages to attract us to the XHTML, but if we are forever in the HTML 4.01 comfortable quilt, the Web will never go forward?

The answer is still a question mark.

　　 Summary

Originally, just for the future of the splendid picture, most of us are willing to turn to XHTML, which is probably a delicate balance in game theory, a game played by users, browser makers, and standard makers, but IE broke the balance: it doesn't support it application/xhtml+xml , so users have to text/html publish XHTML page.

If they are personified: I think "user" is probably a barber Tiaozi Ituge, they are so good for their XHTML page in all browsers are satisfied, but muddy do not know behind the HTML, they do not have a bit of "X" benefits.

The standard-makers--he must be an idealist--were also dissatisfied because the user was still writing XHTML in HTML, not ready to change to XHTML, and the standard-makers were bent on sailing for a better future for the WEB, But found that both the user and browser vendors are doing his best to make trouble.

Browser makers, who have the biggest bargaining chip but have been sitting on the sidelines, are happy to fight and shrug their shoulders.

You may be frustrated with this, but it is the reality of the Web today, admitting it or not admitting it, setting a goal, and then moving forward in a difficult and persistent way, probably the only thing our standard promoter can do.

　　 Notes

1. Nor is there no way, for dynamic content created with PHP or ASP, the best way to negotiate content by detecting HTTP headers is to provide ' Accept: ' to include ' application/xhtml+xml ' requests ' Content-typ E:application/xhtml+xml ' data, while giving other requests for ' text/html ' data. (an article in 456 Berea Street explains this method in detail, in fact, opens the Mozilla/firefox ' about:config ' page and you can find the relevant configuration ' Network.http.accept.default ' to verify that Mozilla sent the correct HTTP headers. This is almost a perfect method (in fact, static content can probably be implemented through the WEB server's content negotiation function), but given that the main purpose of this article is to explore whether XHTML should be used, it is not discussed in detail in the text.
2. Still refers to ordinary users, in fact must admit that the emergence of XHTML for the entire WEB itself is absolutely beneficial to the long-term development.
3. In fact, should not say so absolutely, it should be said that the emergence of XHTML is absolutely necessary, but the benefits of the vast majority of the Web itself, the long-term, now difficult to see the benefits of users or developers, the benefits are negligible.

　　 Reference Documents

1. Ian Hickson, sending XHTML as text/html considered harmful
2. Gez Lemon, it ' s all in the MIME
3. Gez Lemon, specifying a MIME Type
4. Roger Johansson, Developing with WEB standards, recommendations and best practices, part 5:xhtml
5. Network Working Group, the ' application/xhtml+xml ' Media Type
6. Tommy Olsson, Content negotiation
7. The consortium, XHTML Media Types