Comments on: Why XHTML

By: Pam R

Pam R — Tue, 14 Oct 2008 19:22:16 +0000

Brodie Rao Says:
June 5th, 2008 at 4:58 pm

“I’m sorry, but almost none of these points are relevant. If you’re trying to make a case to vendors that XHTML is better because it’s simpler, that’s not true at all. It’s just one more technology to support - HTML is never going away. However, that doesn’t matter to web developers and authors.”

I must agree here, There is a use for both of these formats and I don’t think they will ever both go away.

By: mathiastck

mathiastck — Tue, 10 Jun 2008 23:41:29 +0000

Responding to:
Anne van Kesteren
”
Igor, it shows you haven’t invested much in reading up what’s happening with mobile browsers. There’s actually very few of them which get XHTML right. Most have a forgiving HTML parser so they can render the Web. Now that we see more and more Opera and WebKit on mobile phones (and soon maybe Gecko powered too) they’ll just have the same capabilities as desktop browsers. As Ian already said, parsers are hardly the complicated bit.
”
Most phones don’t have an html browser at all, but most phones support XHTML MP. Admittedly many don’t “Get it right.”, there are many quirky phone browsers. But again, most phones don’t support html.

By: Elliotte Rusty Harold

Elliotte Rusty Harold — Mon, 09 Jun 2008 15:04:49 +0000

And I repeat: that this page is served as text/html does not mean it is not XHTML. It is XHTML because it is well-formed markup in the correct namespace. Except for one funky bit that’s pulled in by one of the ads, it’s even valid.

The MIME type is not what one consults to determine if a page is or is not XHTML. I could label this page audio/mp3 and it would still be XHTML. Do not confuse the name or label of a thing with the thing itself.

I suggested one should publish XHTML. I did not suggest that one should label that XHTML with the MIME type application/xhtml+xml. That is your claim, not mine.

By: Don

Don — Mon, 09 Jun 2008 14:41:49 +0000

Right, I noticed now that you are serving this page as XHTML 1.0 Transitional (that is odd by the way, why Transitional?) but it does not validate - there is an error ‘document type does not allow element “style” here’.

Clearly, the page is parsed as text/html and that’s the only reason it’s readable and not showing a “XML parsing error” message. So what you wrote - “Nothing significant breaks” - is true only because you’re actually not using XHTML (like in serving this page as application/xhtml+xml, as it should be).

By: Anne van Kesteren

Anne van Kesteren — Mon, 09 Jun 2008 14:07:10 +0000

(Oops, seems Henri already replied. Sorry about that. Didn’t think new comments might have been posted meanwhile.)

By: Anne van Kesteren

Anne van Kesteren — Mon, 09 Jun 2008 14:06:01 +0000

Brad, yes that works. http://about.validator.nu/htmlparser/ has sample applications available.

By: Elliotte Rusty Harold

Elliotte Rusty Harold — Mon, 09 Jun 2008 13:06:04 +0000

Funny, I serve XHTML off many pages (including this one) and my statistics show I get a reasonable number of visits from IE users. Clearly IE supports XHTML to some degree. (Like most questions this is not binary: the issue is how much it supports it, not whether it supports it.)

I do recommend not using an XML declaration on XHTML pages because it causes lots of problems for older browsers. However the XML declaration is in no way required for XHTML.

And the warning you cite simply says that there’s not a strong reason to serve XHTML to Mozilla as application/xhtml+xml. If you want to just serve it to Mozilla too as text/html, go right ahead. It does say that you shouldn’t serve application/xhtml+xml to Mozilla unless you’re sure it’s well-formed. That’s reasonable. After all, if it isn’t well-formed, then it isn’t XHTML. But if you are maintaining well-formedness, and you feel like being pedantic, then serve application/xhtml+xml to Mozilla and text/html to IE. Nothing significant breaks.

By: Don

Don — Mon, 09 Jun 2008 06:40:12 +0000

Elliotte,
thanks for answering. I would still argue though, because I don’t agree with the statement that “text/html is just fine if it helps”. I’m sorry, but it’s not fine. I have to repeat myself - IE doesn’t support true XHTML at all (and I wouldn’t count on it supporting it in the near future).

Given that unfortunately IE still holds from 50 to 80% of the browser market (depending on the region of the world) that’s an issue you can’t ignore. And contrary to what you suggest, it’s not ok to have a XHTML webpage and serve it as application/xml+xhtml or text/html depending on what the UA accepts. The reason for that is there are some significant differences in rendering (for instance, the XML declaration will trigger quirks mode in IE6 when served as text/html - ruining the rendering). You can read a warning against using dual-mime on Mozilla Web Authoring FAQ as well.

By: Henri Sivonen

Henri Sivonen — Mon, 09 Jun 2008 05:33:48 +0000

Yes, you can use XSLT with HTML5. In fact, the sample code that comes with the Validator.nu HTML parser shows how to use XSLT on HTML5.

By: Brad Neuberg

Brad Neuberg — Sun, 08 Jun 2008 21:15:51 +0000

Quick question; I know that many XSLT parsers actually parse the XML document into an in-memory representation and then work on that representation; they aren’t necessarily exposed to the XML, but rather to an abstraction of a tree. Some XSLT parsers can theoretically be passed ‘anything’ that can be represented as a tree, whether it was originally in XML or not at the beginning. If HTML 5 has well-defined parsing rules, and can pass you back a tree, why couldn’t you apply XSLT on to that tree, or XPath for that matter? I know there will probably be issues with XML namespaces in that situation, however, but I’m sure there are solutions.

Is this a viable option for getting the functionality of XSLT and XPath along with HTML 5? It reminds me a bit of how Firefox can apply an XPath expression on to the visible DOM, even if it is a messy HTML document since the document has already been parsed into a tree representation and the XPath can just use the nice, in-memory representation.

Best,
Brad Neuberg