Pages: 1
Can anyone show me why you should use XHTML instead of HTML when coding web sites? Because I can't find any convincing arguments. And don't just tell me it's "better" or "newer". I need to know why it's a good idea to mix XML and HTML.
XHTML is XML, not really a mix of the two. The strictness of XML makes for easier validation, but the main thing XHTML gets you is transformation using XSLT to produce other document formats from a given XHTML document. There is a large set of XML processing tools that will work with XHTML, but choke on HTML, which by comparison is a mess. No two parsers read HTML in precisely the same way. I'm not sure but you may also get more predictable rendering from different browsers.
Well, I personally like XHTML, for some features... First of them is the fact that XHTML requires source code to be valid (yeah, I like everything to be clean). The validity thing (not the best description?) is consisted of some rules, like lowercase markup, every attribute being surrounded by a set of quotes and tags require an ending tag. Second reason would be the rule of rendering of special characters (such as ampersands and > and < signs). spacebat described rest 
Thanks both of you for your thoughts. So here is how I see it:
The strictness of XML makes for easier validation.
I am sure HTML 4 strict is just as strict as XHTML 1.0?
XHTML gets you is transformation using XSLT to produce other document formats from a given XHTML document
Is this really true? I mean, I have seen som rare cases of XML using XSLT to transform and style the markup, but XHTML? In theory you might be able to use XSLT when serving XHTML as XML, but has anyone`ever seen a public web site using XSLT?
There is a large set of XML processing tools that will work with XHTML, but choke on HTML.
That is true. But what good are those parsers if they can't parse 95% of the web? Perhaps for internal validation or processing I guess.
XHTML requires source code to be valid
Now here is the interesting part. You say "valid", but in fact, serving XHTML to any browser using the MIME type text/html will actually become invalid HTML to the user agent. HTML does not allow ending slash on empty tags, as an example, but the validator won't tell you that.
This is why W3 wrote appendix c as a guideline for XHTML authors so that the browser wouldn't trip when reading XHTML as HTML.
Anyway, the main problem with XHTML is that IE can't render pages with the MIME type application/xml+xhtml. Not even IE8 beta. So no matter how hard you try being strict and XML compliant - the majority of your visitors will see broken HTML. Some authors use a sniffer so they can at least serve the correct MIME type for the user agents that understand it, but it's still a weak minority.
To me it seems like a bad idea to serve one language to the user agent and then lie about it so the user agent thinks it's something else.
Anyway, it's the strict doctype that is the most important of course, no matter what language you choose. But the question remains; what good is XHTML really when building web sites?
When building web sites, there is no difference wheter you work with HTML4 or XHTML, if it's all correctly processed by a web browser, and it looks well.
I am sure HTML 4 strict is just as strict as XHTML 1.0?
I'd be surprised if its as strict as XML with a DTD/Schema, but I'm not a markup lawyer. And with a schema you can validate your XHTML using a variety of tools, some of which can be linked directly into your application if you like. That makes it easier to apply the strictness in the workflow of a CMS without having it bomb in a browser.
In theory you might be able to use XSLT when serving XHTML as XML, but has anyone`ever seen a public web site using XSLT?
Among many others, the BBC use XML/XSLT for almost everything they do. It allows them to transform their content to suit different devices and make it more accessible to the disabled.
what good are those parsers if they can't parse 95% of the web? Perhaps for internal validation or processing I guess.
Exactly right. If you are scraping pages in the wild, you'll want to use a module that hides the monstrous complexity of handling all the failure modes and inconsistencies. I use Perl's HTML::Parser for that. For internal use, you want sanity, clarity and consistency, all of which are easier to maintain using XHTML and the host of XML tools that can be brought to bear.
You say "valid", but in fact, serving XHTML to any browser using the MIME type text/html will actually become invalid HTML to the user agent.
There is a hurdle to serving up XHTML, and its unfortunate that IE has to be the exception to the rule, as usual. Using content negotiation and possibly user agent sniffing, you determine if the client can handle application/xhtml+xml as the W3C stipulates. If it can't, then you can either send it text/html or application/xml depending on how you want to go. There is an XSL you can reference in the header to make application/xml work with IE.
what good is XHTML really when building web sites?
I think the benefits are pretty clear, but they might not have much weight unless working on something that may become very large with all sorts of business processes intertwined. The IE MIME screwup is the most unfortunate thing about it.
Cheers!
Posts [ 6 ]
Pages: 1
You are not logged in. Please login or register.
