Which XHTML Standard to Support?

ASKER

QPR, I wasn't looking for the latest and greatest. I was more interested in figuring out which standard to support. That decision will depend largely on what current popular browsers support. The W3C doesn't seem to have a listing of browser support for standards.

QPR

They don't do that - they show which is better and why.
Read the URL and they will tell you that you should adopt v2

IE6 does not support XHTML 1.0, so forget about using that if you need to support IE6.

To be correct, XHTML cannot be served with the 'text/html' mime-type.
http://www.w3.org/MarkUp/2004/xhtml-faq#texthtml
That parargaph is not clear, so i'll translate it. They are basicly saying that there is a flaw in their specs and that you should use HTML instead of XHTML when you serve pages as "text/html".

XHTML 2 dropped the attempted compatibility with HTML which is good news, but HTML 2 is still a draft and nobody knows howlong it will take for the W3C to come up with a decent specification. That does not seem to be a piority at the W3C.

Conclusion: You should use HTML 4.01 strict. The strict version does not allow deprecated elements and attributes, that's why it's better than the transitional. But it only makes sense to use the strict version if your code validates.

XHTML is not the next version of HTML. XHTML and HTML are two completely different formats.

And don't trust w3schools.com too much, it's not a reference... just another IE-centric commercial site.

>>Conclusion: You should use HTML 4.01 strict.

I agree with that.
XHTML is supposed to merge HTML with several XML tools, and for that to work browsers would need capable XML parsers. Today IE6 and the IE7 prototype do not have capable XML parsers, and Firefox's parser is limited.

So, what we know as XHTML 1.0 and 1.1 is not really what the specification wants it to be. In basic terms, right now XHTML is nothing but cleaner HTML.

You are welcome to use HTML 4.01, which is the only standard that works reasonably well. XHTML is modeled on HTML 4.01 and right now it is largely the exact same thing.

I would personally recommed HTML 4.01 Strict or XHTML 1.1. They are both basically the same.

For more on Doctypes:
http://www.netbulge.com/index.php?session=0&action=read&click=open&article=1137758659

Esopo.

ASKER

If I were to use XHTML, I would gain the benefits of XML (e.g. repurposing content). Does HTML 4.01 Strict separate content and presentation like XHTML Strict?

None of the benefits of XHTML work in IE6.
HTML and XHTML use exactly the same separation between content and presentation: (x)html=content, css=presentation.

Typically your HTML/XHTML is generated using reusable structural data saved in a database or in XML files.
XHTML is not structural data and is not meant to be reusable.

If you want to send structural data to the user agent, you'll need to send XML. Then you can then tell the user agent to apply an XSLT that transforms your XML (structural data) into XHTML (presentational data). But that's definitely not recommended for a normal public site. Current browsers stop responding when they are busy applying the XSLT. And current browsers don't support all the features of XSLT, making it a headache to have a decent cross-browser compatibility. It's recommended to generate the HTML/XHTML on the server-side using php, java, perl or other server-side language.

If you want to generate your pages on your server by applying an XSLT on some XML (using some server-side XML libraries), then you don't have the choice and you must output XHTML because XSLT cannot generate HTML. In most other cases, if your server is able to generate XHTML, it should also be able to generate plain HTML.

ASKER

@GrandSchtroumpf,

I'm not trying to be an @$$ here. I really am not. However,

1. "Typically your HTML/XHTML is generated using reusable structural data saved in a database or in XML files." -- I somehow doubt that. I think it is more typical that webpages are built staticly (in other words, no database/XML backend). I don't have statistics to support this, though.

2. "XHTML is not structural data and is not meant to be reusable." -- XHTML is an XML document. By that, it means it is structured and reusable.

3. "If you want to send structural data to the user agent, you'll need to send XML." -- Yes, and XHTML is an example of that.

4. "XSLT cannot generate HTML." -- Yes it can. It can generate HTML, XHTML, other XML format, plain text, etc.

I'm a VB.Net developer who uses XML very heavily. So, I'm confident about my XML statements. My question really deals with which version of XHTML will have the best browser support. Thanks.

I think GrandSchtroumpf was offering some extra pointers to help paint a clear picture. There is no direct answer since this is hardly a simple matter in the same way that you did not ask a single question, yet all the infromation to answer your several questions has been laid down.

Summing up:

In today's internet XHTML is nothing but tag soup, a cleaner version of HTML 4.01. if you plan to use any of the XML features other than the cleaner syntax you'd better be working in a closed enviroment and using controlled browsers, because IE6 supports next to nothing and FF is incomplete and buggy.

XHTML only defines the structure of a web page... that's not considered to be structural data.

XML structural data uses its own tags and its own DTD.
For instance a structural book record would look like this:
<book isbn="123456"><author>...</author><title>...</title><description>...</description></book>
The book-DTD would define the structure of a book record, so that anyone who wants to use your book records can access its content.
For instance, a book has one isbn attribute, one or more author child nodes, one title child node and one description child node.

Content/presentation separation has 3 parts:
1. structural data (database/xml) -> "data-level content" (on the server-side).
2. presentational data (html/xhtml) -> "data-level presentation" and "persentation-level content".
3. presentation (css) -> "persentation-level presentation" (on the client-side).

This double content/presentation separation is a little confusing for a lot of people.
A lot of server-side developers don't understand why they need content/presentation separation at the HTML/CSS level since they already have a content/presentation separation at the business-tier/presentation-tier level.

At the data-level, XHTML cannot be reused because it does not comply with any meaninful DTD.
At the presentation-level, there is no difference in content/presentation separation between XHTML and HTML, they both use the same CSS.

http://www.w3.org/TR/xslt
"This specification defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents."
HTML is not XML, therefore XSLT cannot generate HTML.

The real advantage of XHTML is that you can use embedded XML like MathML or SVG.
IE6 does not support XHTML when correctly served as XML.
If you serve XHTML as text/html, then all you really do is to serve incorrect html. You cannot expect a correct behaviour if you use incorrect code.

If you need to support IE6, then don't use XHTML.
The only correct alternative is to have 2 versions of the site, one XHTML for agents that support XHTML and one HTML for agents that don't support XHTML.

And i don't see what makes XHTML cleaner than HTML. You can write clean HTML if you want and you can write messy XHTML if you want.

>>And i don't see what makes XHTML cleaner than HTML. You can write clean HTML if you want and you can write messy XHTML if you want.

Agree. What I mean by cleaner is the XML syntax rules (lowercase, closing tags). It makes more sense and it is easier to parse by automated software.

Also,

>>If you need to support IE6, then don't use XHTML.
I agree that IE can't handle XHTML with all its XML capabilities, but as a tag soup it does a pretty good job. I've managed to create some XHTML 1.1 documents that render accurately in both IE and FF. Again, nothing more than XML syntax on HTML 4.01.

ASKER

I'm sorry to continue this debate about XHTML:

1. "XHTML only defines the structure of a web page." - No, it doesn't. As a matter of fact, I regularly take XHTML and convert text, PDF (via XSL-FO), etc. Text and PDFs are not webpages, but I create them from XHTML.

2. "XML structural data uses its own tags and its own DTD." -- So does XHTML since it is an XML document.

3. "At the data-level, XHTML cannot be reused because it does not comply with any meaninful DTD." -- This is incorrect. There are DTDs for XHTML. You can derive meaning from XHTML tags. For example, <h1> ... <h6> are headings of the document. <cite> is another example of a tag that has definite meaning. The tags in XHTML have meaning to document publishers (though I sometimes wonder what real meaning can be inferred from <i>, <b>, etc.).

4. "HTML is not XML, therefore XSLT cannot generate HTML." -- You are right. HTML is not XML. But we are talking about XHTML, which is an XML document. Take a look at the link you provided; it shows an example of how XSLT generates HTML (section 5.4).

5. "I don't see what makes XHTML cleaner than HTML." -- XHTML is cleaner because it is an XML document. Thus, the document must be at least well formed. In the case of XHTML, we can also validate it against a schema.

6. "You can write messy XHTML if you want." -- No, you can't. If it was "messy", then it would not validate against the DTD. If it doesn't validate, then it's not XHTML.

So, no one knows of an authoritative XHTML Broswer Support table of some sort? My guess is that the different browsers have different levels of support for XHTML. My guess is that it'll be easiest to support 1.0 Transitional, but I would really prefer 1.0 Strict. Does anyone know of such a table?

>>So, no one knows of an authoritative XHTML Broswer Support table of some sort?
What are you looking for? the tags or the XML features?

IE doesn't have an XML parser. To render XHTML pages it uses its HTML parser, which basically means it can only render HTML, and humors XML syntax.

1. 2. and 3.
What I mean is that XHTML and HTML use exactly the same structure, which is the structure of a web page (headers, paragraphs, lists, ...).
XHTML does not have the meaningful structure that you can find in the XML files used for structural data.

4.
The current discussion has been about XHTML vs HTML.
If you use XSLT to generate your web pages, then using XHTML is justified since HTML is not even an option.

5. and 6.
HTML must also validate to be called "HTML".
XML minimum quality enforced by the user agent is indeed a great thing about XHTML, but that's clearly not enough.
The DTD syntax makes it impossible to write a DTD that can identify all possible errors in an XHTML document.
This means XHTML documents need to be validated using a more complex validator, just like HTML.
You can still write messy XHTML that validates by using bad semantics, tables for layout, unnecessary tags, classes and ids, inline styles...
Clean XHTML is not cleaner than clean HTML.

I have nothing personal against XHTML, but IE6 does not support it at all.
That's what your initial question was about: "How are IE6 and FF's support for XHTML?"

XHTML is not better than HTML when used properly. They are just different.
If you don't need the extra functionalities that XHTML offers, then you might as well use HTML which is supported by all user agents.
That's why it's important to understand what those the extra functionalities really are.

Code parsing and re-usability is not an extra functionality. You can do the exact same thing with HTML.
The only difference is that you'll need to use an HTML parser for HTML and an XML parser for XHTML.
If you want to use an XML tool on an HTML document, you can transform the HTML into XML without losing any information. It's only an additional step.

Code quality is not a real extra functionality either since both XHTML and HTML need to be validated using complex validators and since valid code is not enough to ensure real code quality.

> IE doesn't have an XML parser. To render XHTML pages it uses its HTML parser.

IE has an XML parser and it renders XHTML like it renders all other XML: as a node tree.
For IE to display something else than that node tree, you need to force IE to treat XHTML as HTML by serving the page as "text/html".
That's like saying "here is an apple" while giving someone a raw onion, and hope the person won't notice the difference and will start eating the onion as if it was an apple.

ASKER CERTIFIED SOLUTION

LeeKowalkowski

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial