After all, why choose XHTML via HTML?

Question

I wonder why I should use XHTML instead of HTML.

XHTML is supposed to be "modular", but I have not seen any server language use any of them.

XHTML is also more rigorous, and I see no benefit. What does XHTML offer that I feel so bad? How does this make my code “better”?

EDIT: Another question I found in the comments: Does XHTML process faster than HTML?

EDIT2: After reading all your comments and links, I really agree that another publication deserves the correct answer, so I chose the one that is directly related to the best source.

It has also been shown that people ignore the green comment without even reading it.

Answer 1

You should read Beware of XHTML , which is an informative article that warns of some XHTML errors via HTML.

I write pretty well about XHTML until I read it, but it makes a few valid points. Including the following bit:

XHTML 1.x is not "future compatible". XHTML 2, currently in its development phases, is not compatible with XHTML 1.x feedback. XHTML 2 will have many significant changes in the way you write and structure documents, and even if you already have your site written in XHTML 1.1, you usually need to rewrite the complete site in order to convert it to the corresponding XHTML 2. Simple XSL Conversion will in most cases insufficient, because some semantics will not be translated correctly.

HTML 4.01 is actually more compatible with the future. A valid HTML 4.01 document written at current support levels will be valid HTML 5, and HTML 5 will focus on browser and W3C developers.

Future compatibility can be huge when working on some projects. The article talks about a few other good points, but I think this may have stood out for me the most.

Make no mistake in the article to criticize against XHTML, the author does talk about the good points of XHTML, but it's good to know the flaws before diving.

Answer 2

I was about to add this as a comment to one of the other posts, but it increased slightly.

What is the main point that most people seem to be missing is the purpose of XHTML. One of the main reasons for developing the XHTML specification was to decentralize presentation-related tags in markup and defer presentation in CSS. Although this separation can be achieved using simple HTML, the specification does not contribute to this behavior.

Separation of meta-markup and presentation is an important part of the development of a “programmable network” and will not only improve SEO and access to on-screen readers / text browsers, but also make your site easier to analyze for those who want to access it programmatically way (in many simple cases, this may negate the need to develop a specific API or even just let client scripts do things like easily identify phone numbers). If your webpage complies with the XHTML specification, it can be easily moved using XML-related tools and things like XPath ... which are fantastic news for those who want to extract certain information from your site.

XHTML was not designed to be used on its own, but using many other technologies. It relies heavily on the use of CSS for presentation and provides the foundation for things like Microformats (whether you like them or hate them) to offer standard markup for presenting shared data.

Do not be fooled by a crowd that thinks that XHTML is insignificant and too overly restrictive and meaningless ... it was created with a goal that 95% of the world seems to be ignored / not known.

In any case, use HTML, but use it for what it is good for, and use the same approach when viewing XHTML.

---

Regarding parsing speed , I believe that the difference between actual documents between XHTML and HTML will be very slight. The compromise will only be explained by how you describe the document using the available markup. XHTML tags tend to be longer due to required attributes, proper closure, etc., but will not refuse the need for any presentation markup in the document itself. In this case, I think you are talking about comparing one type of apple with a completely different type of apple ... they are different, but they are unlikely to have any meaning (in terms of parsing and rendering) when all you want , is a healthy, tasty apple.

Answer 3

For a website visitor, it probably makes no visible difference. In addition, XHTML is usually more painful because at least one widespread browser still does not know how to handle it, and you will need to use it as text / html in this case (which gives invalid HTML).

If your HTML will be regularly processed by automated tools rather than human-readable, then you may want to use XHTML because of its more rigorous structure and be easier to parse XML (from an application point of view, that XML is essentially easy to parse, though).

In addition, I see no good reason to use it. XHTML was created as part of the use of XML features for HTML and basically boils down to “HTML 4 with a few annoying side effects” (IMHO, at least).

Answer 4

Use HTML (HTML4 Strict or HTML5).

• HTML can make full use of CSS, can be verified and parsed unambiguously. The separation of structure and presentation was done in HTML4, and XHTML simply continued it.

• All browsers support HTML. Only some browsers support XHTML, and those that do often have more mature and better tested and optimized HTML support (this is due to the fact that a tiny fraction of the pages use XML mode).

• If you are interested in IE and Google, you should use HTML or a subset of XHTML and HTML defined in Appendix C of the XHTML specification. The latter is almost the worst of both worlds, because such XHTML cannot be created with standard XML tools, cannot use the new extension mechanisms that are new to XHTML, and has additional restrictions compared to those available only in HTML.

• XHTML1.0 is now over 10 years old, it was developed a "Web1.0" time, and, as the W3C head said, Looking back, this did not work, and a better approach is needed . W3C HTML5 is written as we speak and address the needs of the web applications used today, and has very good backward compatibility.

• HTML5 closes many gaps between HTML4 and XHTML1 (for example, adds built-in SVG, MathML and RDF), clears the language above what was done in XHTML1.0 and XHTML1.1.

• XHTML2 will not be supported by web browsers for the foreseeable future. It will probably never be supported (all browser vendors pretty much support [X] HTML5, some have already stated that they will not implement XHTML2).

---

XHTML1.0 has exactly the same semantics and separation of views from the structure as HTML4.01. Anyone who says otherwise has not read the specification . I urge everyone to read the specification - surprisingly short and uninteresting.

• Style sheets were introduced in HTML4.01 and were not changed in XHTML1.0.
• Presentation elements are deprecated in HTML4.01 and have not been removed in XHTML1.0.

XHTML myths .

---

In HTML and XHTML there are no conclusive differences that would make parsing one slower than the other. It depends on how the parser is executed.

• SGML and XML parsers must load and parse the entire DTD in order to understand objects. Only this is usually more than an analysis of the document itself. HTML parsers almost always “cheat” and use hard-coded objects and element information. XHTML parsers in browsers are also deceiving.
• HTML analysis requires processing of implied start and end tags, and in the real world, HTML requires additional work to process non-local tags.
• Proper analysis of XHTML requires tracking XML namespaces.
• Dragon XML rules require that each character is encoded correctly. HTML parsers can get away from this, but OTOH they need to look for <meta> .

The overall difference in the cost of parsing is tiny compared to the time it takes to download a document, create a DOM, run scripts, apply CSS, and all the other things that browsers need to do.

Answer 5

I am surprised that all the answers here recommend XHTML via HTML. I strongly believe that you should not use XHTML for the foreseeable future. That's why:

• No browser interprets XHTML as XHTML unless you use it as mimetype application/xhtml+xml . If you just use it with the default mimetype type, all browsers will interpret it as HTML - for example, accept unclosed or incorrectly nested elements.

• However, you should never do this, since Internet Explorer will not recognize application/xhtml+xml and will not be able to fully display the page.

• There are significant differences in the DOM between XHTML and HTML. Since all so-called XHTML pages are currently executing as HTML, all javascript codes are written using the HTML DOM. If mimetype XHTML support becomes significant enough to convince people to start using it, most of their javascript code will break - even if they think their pages are being validated as XHTML.

Answer 6

Instead of continuing the discussion of HTML 4.01 Strict vs XHTML Strict, I would suggest starting using HTML 5 today. John Resig, the author of jquery, made a similar proposal last year on his blog.

An HTML 5 document, in which beautiful simplicity will bring standards to all browsers (including IE6).

 <!DOCTYPE html> 

What is it.

HTML 5 contains some interesting new features, such as the <canvas> , which could potentially push javascript application development to the next level. HTML 5 also has proper media support (and media is a pretty important aspect of the Internet these days!) In the form of <video> and <audio> tags.

If you like the syntax of XHTML, i.e. closing empty tags such as <br /> , which is fully supported in HTML 5. From Karl Dubost W3C post Learn how to write HTML 5 :

autocomplete tag is allowed and conforms to HTML 5.

XHTML2 pays relatively little attention compared to HTML 5. It is becoming increasingly apparent that HTML 5 is the future of markup on the Internet. Microsoft's latest browser, IE8, still displays XHTML as text / xml as text / html.

Microsoft has a co-chair of the W3C HTML working group and implies support from them for HTML 5. All browser vendors have publicly announced their support for HTML 5.

At the end of the day, even if XHTML2 regains support from the industry, it will not be a serious problem having two competing standards, as it was in the past. Both languages ​​support XML namespaces (in the case of HTML 5, HTML serialization, i.e. DOCTYPE switching).

Answer 7

Take a look at http://www.w3.org/MarkUp/2004/xhtml-faq#need . There are several good reasons besides modulation.

I use XHTML because it is more rigorous and more explicit. HTML is fancy and browsers should accept things like <b><i>sadasd</b></i> . Although this is a really simple example, it can also become more confusing, and different browsers can distinguish things differently.

I also believe that XHTML should be “faster” because the browser does not need to perform such “reparations”.

Answer 8

Some differences are as follows:

• XHTML tags must be properly nested
• Documents must have one root element
• XHTML tags are always lowercase
• Tags should always be closed (for example, using the <br> tag in XHTML should have a closing tag <br /> or <br></br> in XHTML)

Here are some links to it

wiki XHTML

wiki HTML vs XHTML

Answer 9

As a programmer, you should be VERY worried about your code. HTML is ugly and follows a few rules.

XHTML, on the other hand, turns HTML into the right language, following strict structural and syntactic rules.

XHTML is best for everyone, as it helps move the website to a point where everyone (all browsers) can agree on how to display the web page.

XHTML is a descendant of XML, and it’s a lot easier for us for parsers designed to parse syntactically valid XML documents.

If you do not see the benefits of XHTML, you can also use MS Word to create your HTML documents.

Answer 10

XHTML allows you to use all the tools that are designed for XML. Among them are XSLT, embedding SVG, etc.

Answer 11

XHTML makes you be careful.

For example, in HTML you can write:

 <img src="image.jpg"> 

This is not very logical, because the img tag never closes. However, in XHTML you need to carefully close the tag, for example:

 <img src="image.jpg" /> 

I like to use something that makes me be neat.

Steve

Answer 12

Subtitles to XHTML 1.0 recommendation:

Reformatting HTML 4 to XML 1.0

Today, there are many tools for processing XML. Using XHTML, you provide a huge set of tools to work on your pages and programmatically extract information.

If you used HTML, that would be possible. There are tools for parsing HTML DOM trees. However, these tools can often be more specialized than XML tools. You cannot find your favorite HTML compatible XML processing tools. In addition, there are currently so many uses for XML that you can use XML for any other part of the application; why not use the same XML parser to parse your web pages? This is the motivation of XHTML.

If you are already familiar with HTML 4.01, you have an installed project using HTML 4, and you do not have too much time, just go with HTML 4.01. If you have free time, study XHTML 1.1 anyway and start your new projects in XHTML 1.1 - there is no harm. If you are using something other than HTML 4.01 or you are not familiar with HTML 4 at all, just learn XHTML 1.1.

Answer 13

Using XHTML with the correct DocType will force the browser to display content in a more standard (strict) mode. This leads to the fact that different browsers behave better and, most importantly, are more similar to each other. This makes it easier to work as a web developer, as it reduces the number of browser-specific settings needed to make the content look the same in all browsers.

Quirksmode.org has a lot of good information on this.

Answer 14

Interesting development: XHTML 2 working group expected work to end At the end of 2009, W3C increased HTML 5 resources

2009-07-02: Today, the Director announces that when the charter of the XHTML 2 working group expires on schedule at the end of 2009, the charter will not be renewed. By doing this and increasing resources in the Working Group, the W3C hopes to accelerate the progress of HTML 5 and clarify the position of W3C regarding the future of HTML. The FAQ often asks questions about the future results of the XHTML 2 working group and the status of various discussions related to HTML. Learn more about HTML activities.

Well, I think it makes the future of HTML pretty clear.

Answer 15

In my opinion, strictness, at least theoretically, is a good thing, because in HTML you do not need to be strict, and because of this HTML5 is garbage, browsers have improved error correction algorithms that will do everything possible from broken HTML . The problem is that the algorithms are not exactly the same and will lead to really strange behavior that you cannot predict. With XHTML, on the other hand, you usually have beautiful, valid XHTML, and therefore error correction algorithms are not needed, i.e. The behavior of the entire browser is predictable. In addition, strong code makes it easy for your tools to work with code. Thus, in fact, you have nothing to lose using XHTML, but there are some possibilities to achieve. Things will get worse with plain HTML when HTML5 finally comes out, and "being open at what you accept" will lead to the strange behavior described. But at least then this is a standardized weird behavior. Sigh.

On the other hand, if you use a good IDE, such as Visual Studio, it is almost impossible to create broken HTML code, so the result will be the same.

Answer 16

Use XHTML

• Fails fast . If there are any inconsistencies, they will be found during verification.
• It encourages better design by separating semantic markup from presentation, etc.
• It is structured , which means that you can consider it as a data object and run all kinds of queries with it. For example, you can find all addresses or quotes on your website.
• You can do build time optimization . Since this is well-formed XML, you can easily perform search / replace operations during assembly. Or any document management and manipulation.
• You can write XSLT or other conversion scripts to programmatically convert your XHTML to other platforms. For example, you might have XSLT for iPhone, which will convert all XHTML to make it compatible or more convenient for iPhone.
• You are a future check . Converting XHTML to new semantics again, very simple using conversion.
• Search engines will continue to evolve to collect more semantic information as part of a programmable website .
• DOM operations are more reliable because they are structured.
• From the point of view of the algorithm, it provides easier and faster parsing .

Answer 17

XHTMl is a good place to use because if you want to have valid code, you will need to provide some aspect of assistance for the community with disabilities because screen readers need alt and the names of image parts and link tags. This should be faster for parsing, because unlike HTML, the parser did not need to check if the tag was closed correctly, if it was correctly nested, etc. It is also better to use it, because yes, it is strict, but it helps you think more logically (in my opinion) when it comes to learning programming languages.

Answer 18

I believe that XHTML is faster (or should be) for parsing. A valid XHTML document needs to be written in a stricter specification, because errors are fatal to parse, while HTML is more lenient and allows for the above-mentioned oddities, like my comments like closing closing tags, etc. I found this useful in uncovering the differences between HTML and XHTML syntax:

http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Parsing

The reason you can use XHTML via HTML may be if you intend to use mobile users as part of your audience. If I remember, many phones use something more than an XML parser, rather than HTML to display the Internet. If you write for desktop browsers, HTML is likely to be acceptable.

However, if you intend to use the data as text / html anyway, you should use HTML:

http://www.hixie.ch/advocacy/xhtml