HTML and XHTML - Some Basic Question

[SilentBobSC]

But how do you serve it? As text/html or as an application? Only XHTML 1.0 can be served as text and then it is like regular HTML (although with few differences such as not using capital letters for the tags, and so on).

The system I work with most frequently is DotNetNuke, the skins I create usually use the XHTML 1.0 Transitional Doctype to account for the varied code output by both the core CMS as well as 3rd party modules.

[felgall]

The system I work with most frequently is DotNetNuke, the skins I create usually use the XHTML 1.0 Transitional Doctype to account for the varied code output by both the core CMS as well as 3rd party modules.

Sounds like you are using HTML.

XHTML pages don't display at all if there is any validation error (or your visitor is using Internet Explorer 8 or earlier).

[AlexDawson]

XHTML doesn't stand for anything in particular as far as I know (or at least, the W3C don't say that each letter is a reference to a particular word)

Just a quick correction for you molona, XHTML does stand for something (and it is "Extensible Hypertext Markup Language"), it inherited the Extensibility X from XML

[jamesicus]

Two handy references:

Activating Browser Modes with Doctype - Choosing a Doctype

Web-Sniffer HTTP Request & Response Header Viewer - can be employed to check how any Web Page is being served to various Graphical Browsers (specified via User Agent window).

James

[felgall]

Two handy references:

Activating Browser Modes with Doctype - Choosing a Doctype

Web-Sniffer HTTP Request & Response Header Viewer - can be employed to check how any Web Page is being served to various Graphical Browsers (specified via User Agent window).

James

Theymay be useful references but neither of them has anything whatever to do with this topic since neither of them relate to the difference between HTML and XHTML. The first reference is about the doctype and the second about what HTTP protocol the page is using but neither covers the MIME type which is what determines whether a page is HTML (with MIME type text/html) or XHTML (with MIME type application/xml+xhtml).

[jamesicus]

Theymay be useful references but neither of them has anything whatever to do with this topic since neither of them relate to the difference between HTML and XHTML. The first reference is about the doctype and the second about what HTTP protocol the page is using but neither covers the MIME type which is what determines whether a page is HTML (with MIME type text/html) or XHTML (with MIME type application/xml+xhtml).

You are wrong. Doctype - its use and effect - has been referenced several times in this thread and use of the Web-Sniffer HTTP Request & Response Header Viewer will certainly reveal the MIME type. Please check things out before you opine so imperiously.

James

[Stomme poes]

Off Topic:

imperious opining! : )

[felgall]

You are wrong. Doctype - its use and effect - has been referenced several times in this thread and use of the Web-Sniffer HTTP Request & Response Header Viewer will certainly reveal the MIME type. Please check things out before you opine so imperiously.

James

The doctype has nothing to do with whether it is HTML or XHTML only whether the CSS should be treated as standard mode (if a valid doctype is present) or quirks mode (if no doctype or invalid doctype).

Examining the headers doesn't help any in actually setting the page to use the appropriate MIME type. So that web sniffer only touches peripherally on the topic.

Just because people sometimes go off the topic in a thread (in this one mostly due to misunderstanding what a web browser does with a doctype) doesn't mean that others shouldn't try to bring it back on topic.

Doctypes have nothing whatever to do with whether a web page is HTML or XHTML. You can use either a HTML or XHTML doctype to define your HTML page. You must use an XHTML doctype for an XHTML page but since both HTML and XHTML can use an XHTML doctype iit does not tell you anything about whether the page is HTML or XHTML.

To set up an XHTML page you need to do one of the following.
1. Set up your web server so that it has an extension defined for web pages that will insert the appropriate MIME type.
2. If you don't have access to the server config file then you can add an appropriate line to the .htaccess file (or equivalent for servers not using Apache).
3. You can use a server side language to insert the MIME type header in front of the page content (as I did with the example XHTML page that I posted earlier in the thread).

Iif you don't do any of those things then you are not usiing XHTML but are instead using HTML regardless of what doctype you use.

Trying to open the web page in Internet Explorer is a much easier way to check if the page is HTML (displayed) or XHTML (offered for download) than using any sort of sniffer that you can download or run from a web site since most people already have a copy of Internet Explorer (the ultimate XHTML sniffer) installed on their computer and they don't have to bookmark it to fiind iit again since it is easy to find on their computer whenever they need to check if a web page is HTML or XHTML.

[TomB]

Browsers do care, if you actually use
XHTML 1.0 is nothing more than a reformulation of HTML 4.01 as an application of XML 1.0. The only purpose for its existence was so that you could parse it with an XML parser and include elements from other XML namespaces. Since Internet Explorer doesn't support it and most markup authors don't know what they are doing, XHTML markup is almost always served as HTML. That means none of the alleged benefits apply; rather the opposite: you depend on (non-standardised) browser error handling since all you are really using is invalid HTML.


That's most likely because you are serving your 'XHTML' as HTML and because you are using a limited subset of XHTML syntax. IE supports most of HTML and its error handling lets you get away with the invalid markup.

The idea that serving HTML content as XML is pointless is incredibly short sighted

By allowing the document to be parsed as XML, it allows it to interact seamlessly with other XML technologies. For example. XSLT. It's incredibly useful to transform XML data into an XHTML document using XSLT (either server side or clientside) it allows for separation of content and presentation.

Whether or not end users web browser's can handle the XHTML page correctly is almost irrelevant, it's the fact that external web services can use your website with far greater ease because it's well formed, easy to parse and easy to load content from is where serving as XML really shines is.

The non-standardised error handling isnt a problem, because the only major browser which doesn't support XHTML is IE, which handles the errors in the way we want. Everything else can correctly parse the XHTML.

[AutisticCuckoo]

The idea that serving HTML content as XML is pointless is incredibly short sighted

Is it? People have been using pretend-XHTML since 1999 and it's still as pointless today as it was 10 years ago. And 10 years is a pretty long time on the web.

By allowing the document to be parsed as XML, it allows it to interact seamlessly with other XML technologies.

But it mustn't be parsed as XML if it's served as text/html! That says it's HTML and should be parsed as HTML or SGML.

For example. XSLT. It's incredibly useful to transform XML data into an XHTML document using XSLT (either server side or clientside) it allows for separation of content and presentation.

Yes, (server-side) XSLT can be very useful. Keep your input data as XML and apply XSLT to transform it to a format that web browsers can handle.

So you use XSLT to transform the XML data into HTML. If, one day in the distant future, XHTML becomes a viable, well-supported option and you need to use elements from other XML namespaces, guess what: change <xsl&#58;output method="html"/> into <xsl&#58;output method="xml"/>, modify the doctype declaration and add the XHTML namespace to the <html> tag. And you're done.

In other words: using XSLT is no excuse for serving the result as pretend-XHTML. XSLT can serialise the DOM as HTML just as well as XML.

Whether or not end users web browser's can handle the XHTML page correctly is almost irrelevant, it's the fact that external web services can use your website with far greater ease because it's well formed, easy to parse and easy to load content from is where serving as XML really shines is.

Again you are mistaken. If you serve the document as text/html it must not be parsed as XML. You may as well try to load it into PhotoShop and claim it's a JPEG image.

If you use XML+XSLT on your server, you can easily serve content as HTML to browsers and XML or XHTML to web services.