Analysis of the disadvantages of the self-closing of XHTML tags _ experience Exchange

If you are familiar with XML-related development, you may also be accustomed to writing, thinking that any element that does not have a child node in XML can be written in this way, so that tags with no content in XHTML can be written as well. XHTML, of course, allows any tag to be written in a closed way, but browser compatibility poses a new problem, IE does not correctly recognize the custom of some tags.

Try entering the following XHTML code and browsing in IE: <p>hello <script type="text/javascript" /> world</p> you will find that you can only see the front of hello but not the back of the world, this thing is very inexplicable. There may be a lot of people who have had this problem and spent a few hours on it and couldn't find a reasonable explanation.

The explanation comes from another piece of code similar to <p>hello <textarea /> world</p> this: can you get a reasonable explanation of how the display works in IE? We can see the previous Hello normal display, and the world behind it is shown in textarea, which proves that IE did not correctly identify the TEXTAREA tag has been closed, but when it is not closed, and the following content is recognized as textarea internal content.

That's when we know why the previous code doesn't see the world in the back because it's being identified as part of the script. This means that when we use XHTML, we do not use the same way as XML, and only a handful of tags that do not need to be closed can be written in a closed form, and other tags, even if there is no content, are best used in pairs.

Finally need to remind everyone is that, in fact, the parser of the mentally retarded not only ie, many places may encounter due to the parser of the problem, so we are writing XHTML or to accommodate some old HTML inherited habits, You can't just write as if you think you can do it as if you were really XML. Don't believe it? Then try another one: <p>hello <br></br> world</p> pay attention to the display effect of IE and opera.

Update: Some readers think that my example does not conform to the XHTML specification, so please read the XHTML specification first. The Chinese translation of the Empty Elements section reads as follows: "An empty element must either have an end tag or end with a/>, such as <br/> or HTML compatibility standard for information about ensuring backward compatibility with HTML4 browsers. "It can be seen that the specification also gives examples of Compatibility Issues section, which reads as follows: "Although XHTML1.0 documents are not required to be compatible with existing browsers, this is not difficult to do in practice." "Therefore, XHTML does not stipulate that documents must be backward compatible, and I give examples of legitimate XHTML document fragments that can be validated by the Markup Validation Service when appearing in full XHTML."

Update again: in fact, the purpose of my writing this article is not to emphasize compliance only with XHTML specifications, nor is it to emphasize that conforming to XHTML and compatibility with HTML4 is enough, but should consider more situations that need to be compatible. For example, your CMS allows users to submit HTML, submitted HTML through Sgmlreader or other methods formatted as XHTML, and perhaps other XML processing, it is possible to submit the user's <textarea></ Textarea> is converted to <textarea/>, in which case you need to trace debugging to find out the problem is not easy, because the XML processing does not violate any specification, each step of the processing is consistent with semantics. In addition, it is best not to write the <br/> as <br/>, because some of the parser of the mentally retarded can not be properly identified simply because a space is missing.