| SitePoint Sponsor |
For instance, if you style the TBODY element but don't have the <tbody> or </tbody> tags in the markup then the rendering will differ depending on whether you serve it as text/html or XML.HTML Code:<table> <tr><td>foo</td></tr> </table>Code:tbody { background:lime; }
Simon Pieters
Ah. That makes sense. Thanks, Simon.
We miss you, Dan Schulz.
Learn CSS. | X/HTML Validator | CSS validator
Dynamic Site Solutions
Code for Firefox, Chrome, Safari, & Opera, then add fixes for IE, not vice versa.
@zcorpan: Thanks for covering those replies.
I first started using HTML 1993/94 (can't remember exactly). Just for personal use, mind you. Back in those days there were no ways to style your content at all, which is why the structuralist view comes rather naturally to me.Originally Posted by Ferrarislave
I was late to jump on the CSS bandwagon, since I believed for a long time that rendering and styling should be left to the user agent. Can you tell I'm not into marketing?
I first played with 'XHTML' (served as text/html, of course) in 2001, I think. A year later I read Hixie's article and realised how foolish this whole thing was. I then got into the whole content negotiation thing ...
Now I'm trying to make others understand the fundamental differences between HTML and XHTML. Some accuse me of being 'anti' XHTML, which is not true. Using XHTML would be great, if only it worked.
Birnam wood is come to Dunsinane
Why are there so many books that tell us we should be using xhtml, and why is there this big "standards compliance" movement (Jeffrey Zeldman, Jeremy Keith et al) that insists we should be using xhtml/ css, if it "doesn't work"? What is the argument for using xhtml as opposed to html 4.01?Now I'm trying to make others understand the fundamental differences between HTML and XHTML. Some accuse me of being 'anti' XHTML, which is not true. Using XHTML would be great, if only it worked.
I've come across the arguments against using xhtml before, but what's your take on what we should be doing?
He answers that question more then once in this thread. It is OK to use XHTML; however, it is of no benefit to you at the moment if you serve it as text/html. The only benefit you might possibly have in the future is if you serve your pages as true XHTML. Currently the only differences between HTML 4.01 Strict and XHTML 1.0 Strict are the closing tags. I perfer the syntax, and im used to it, so I stick to XHTML. It is not technically "correct", but I still do it because there is no harm in it.
Once again, thanks to Tommy for explaining the topic so indepth. I truely didn't understand any of it prior to read this topic. Kudos!
Yes, it's threads like these that make one realise how much one still doesn't know.
I can think of two answers to that question:
- Those authors aren't fully aware of the differences between XHTML and HTML, but believe the former to be a newer and cooler version of the latter.
- I have missed some important detail that actually makes XHTML (served as text/html) better than HTML.
I don't know if Jeffrey Zeldman still advocates XHTML indiscriminately. When he wrote Designing With Web Standards, XHTML was all the rage and the harsh reality had not yet been exposed.
I'm not sure Zeldman/Keith insist on XHTML. A web standards evangelist would rather advocate semantic markup separated from presentation and behaviour. Strict/Transitional then becomes a much more important issue than HTML/XHTML.
You're asking the wrong guy here, remember?
XHTML proponents like to emphasise that well-formed XML-based markup makes the document's contents easier to use with tools other than browsers. That is true. The question is how often this is useful, but it's an undeniable advantage of XHTML. It presumes, however, that the XHTML is served as an application of XML; if it's served as text/html, user agents must parse and interpret it as HTML.
XHTML proponents also say that XHTML is superior to HTML because it allows CDATA sections and inclusion of elements from other XML namespaces. That is also true but, again, requires the document to be served with an XML MIME type.
Another common argument is that XHTML is more 'future-proof' than HTML. The difference, if there is one at all, is negligible provided that you write your HTML in a good way (i.e., as similar to XHTML as possible). XHTML2 is not going to be backwards compatible with XHTML1. That means you'll probably need to rewrite XHTML1 documents as well as HTML4 documents in order to convert them to XHTML2.
Other 'advantages' one often hears are that XHTML is more strict or more semantic than HTML (not true; they are identical in that respect); that CSS can only be used with XHTML (certainly not true); that XHTML – even when served as text/html – is rendered more quickly than HTML (not true; actually the opposite since XHTML UAs don't use incremental rendering as of yet); and that mobile phone browsers can only handle XHTML (not true, since that would limit the 'Web' to a few thousand pages for those users).
You're welcome!
Birnam wood is come to Dunsinane
XHTML served as text/html can be harmful, see link
Sending XHTML as text/html Considered Harmful
Technology is dominated by two types of people:
those who understand what they do not manage,
and those who manage what they do not understand.
Hmmm, I was just going to say that probably the main advantage of the current popularity of XHTML is that it is leading more and more people to look into standards-driven coding, but Ian Hicks' article seems to suggest that it is actually leading people into potentially troubled waters because they're dealing with things they don't fully understand.
I'm not sure which I think is worse - people still old school coding with no doctypes and combining content and presentation or people making an effort to learn semantic coding but using incorrect doc/mimetypes.
If their only 'mistake' is using the 'wrong' MIME type, there's neither harm nor foul in my opinion. Only a bit of ignorance.
But people who use an XHTML doctype declaration with uppercase element type selectors in their CSS, or use document.write() to generate parts of the page, or use .innerHTML in their scripts ... those are the ones who have harmful behaviour. For themselves, and perhaps for others as well. In other words, people who rely on HTML-only features and still believe they're using XHTML. That's what Hixie means by 'harmful'.
Especially when they also boast an 'Valid XHTML 1.0 Strict' icon on their site.
Birnam wood is come to Dunsinane
Tommy - I guess I don't know quite as much as I thought I did - or to put it more accurately, I knew a lot of this but hadn't totally understood it. Is there a book you'd recommend that covers this area - I feel as a webmaster I ought to understand this as fully as possible - but I don't want to keep bugging you about it
I haven't seen any book that explains this (but that doesn't mean that there aren't any).
Feel free to 'keep bugging' me.
Birnam wood is come to Dunsinane
OkI haven't seen any book that explains this (but that doesn't mean that there aren't any).
Feel free to 'keep bugging' me.
What are the benefits of serving XHTML with the correct mime type?
How is it actually done?
If you've answered this before, can you ref. the thread and I'll read it.
The benefit is that it will actually be recognised as XHTML by user agents that support it.
You'll be able to use CDATA sections within your markup; mix in MathML, SVG, or elements from other XML namespaces; and you can link your style sheets through PIs instead of <link/> tags.
Your web server must send the proper HTTP headers. It cannot be done with markup within the document or with client-side scripting, because the user agent needs to know the content type before starting to parse the document.
You can make your web server send the right Content-Type header, but how you do that depends what server you're using. In Apache, you can set the application/xhtml+xml MIME type for files with a '.xhtml' or '.xht' extension by the following directive (in a .htaccess file or in /etc/httpd.conf):
You can also use server-side scripting to send the right header, like the header() function in PHP.Code:AddType application/xhtml+xml .xhtml .xht
If you observe certain constraints when writing your markup, you can use content negotiation to serve XHTML as application/xhtml+xml to user agents that support that, and HTML to others. I've written a short article about content negotiation with PHP that may be of interest. If you can do this, though, you may just as well use HTML 4.01 Strict, because you can't use any of the 'benefits' of XHTML anyway.
Birnam wood is come to Dunsinane
Good morning Tommy
Ok, I've been doing some reading overnight. The way I read it it, XHTML should be served as application/xhtml+xml, but can be served as text/html, as long as certain backward-compatibility rules are followed. (I guess at the moment I am serving it as text/html, sometimes without following those rules. I knew about some of the rules but didn't realise they were connected with this issue). I can see that this is not technically correct - but it works, and is less complicated than the alternatives. But I should at least make sure my colleagues and I are sticking to those backward-compatibility rules!
Reading the article on the Wasp site - http://www.webstandards.org/learn/ar...skw3c/sep2003/
The benefits of serving as application/xhtml+xml are a bit vague - "browsers will handle code more efficiently", "fast track rendering" etc. Also you mention "it will actually be recognised as XHTML by user agents that support it". I'm tempted to ask, "so what?". Currently it is recognised as html, and it works for everyone. But here I can see your point - we might just as well write HTML 4.01 and not have to worry about these issues! I also know that in order to persuade people we should be serving as application/xhtml+xml, I'd need more concrete arguments. Managers will see that the existing set up works, and will not be worried about such details. Developers will have to change the way they write css (and some of them are still using table based layouts and old school javascript stuff). I have enough trouble at the moment trying to convince reasonably standards-savvy developers that footers ought to be placed at the bottom of a page!
I guess it boils down to three alternatives:
- Use HTML 4.01
- Use XHTML, served as text/html, using compatibility rules
- Use content negotiation to serve as xhtml+xml to decent browsers and text/html to IE
Realistically I can see what will happen. People will see that serving XHTML as text/html works. They won't see the advantages of serving as xhtml+xml, and they will see HTML 4.01 as a backward step. The middle compromise, I agree seems wrong, and isn't really "standards compliant". Maybe it's nevertheless the most pragmatic choice?
Re: content negotiation. For corporate reasons I am using Microsoft solutions, so it's currently .asp moving toward .net, and IIS5.
Yes. The reason for these 'compatibility' rules is that when served as text/html the document is HTML to all intents and purposes. Thus it must be possible to parse and interpret as HTML, which means that you can't do anything like this:
(Although it's perfectly valid XHTML, it will ruin the page completely when interpreted as HTML, because the parser will be looking for a non-existing </script> end tag.)HTML Code:<script type="application/javascript" src="x.js"/>
Another way to phrase the MIME type issue is this: "If you want to use any XML features of XHTML, it must be served as application/xhtml+xml, application/xml or text/xml."
That's indeed vague, and not particularly correct either. An XML parser can be marginally faster than an SGML parser, but to say that it 'will handle code more efficiently' is not really true. And the speed difference should be negligible for any reasonably sized document. The download speed is likely to be much more of a bottleneck in any case.
The 'fast track rendering' is also incorrect. With contemporary browsers it's rather the opposite. All HTML parser/rendering engines support incremental rendering, i.e., that the elements are rendered as soon as the browser has read it. But no browser currently supports incremental rendering for X(HT)ML, AFAIK. That means that the entire document must be downloaded and parsed before rendering starts. The total time (download+parse+render) is about the same (maybe a hair faster for XHTML), but the perceived speed is better for HTML, because something happens sooner on the screen. Again, the differences are probably not detectable for 'normal' pages.
Certainly. But you cannot use any features that XHTML has but HTML doesn't. You cannot use CDATA sections. You cannot include MathML, SVG, ... You will have to use a validator to find well-formedness errors, because user agents apply HTML rules when parsing and will do the best they can if elements are incorrectly nested (an XML parser must abort).
If all you need is that it 'works for everyone', HTML 4.01 Strict is probably the doctype you should use.
I doubt that there are any. Personally, I'd feel foolish relying on parser bugs (to avoid sprinkled slashes about the page), but I realise that few others care about such things.
And there's no harm in using XHTML-P ('P' for 'pretend', my tongue-in-cheek name for XHTML-as-text/html), as long as you also make sure that it still works when served with the 'proper' MIME type. This is often overlooked (or, more likely, unknown by the authors). An 'XHTML' document that doesn't work when processed as XHTML is 'harmful' IMHO.
This is not mentioned explicitly in the XHTML 1.0 specification, which is a shame. The spec authors probably thought it was self-evident, but it apparently isn't.
Which is rather ironic, since that's what they're using (as far as browsers are concerned).
My script can easily be ported to ASP. I don't know .NET, but I'd be surprised if it weren't possible there, too. OTOH, for obvious reasons Microsoft are probably a bit reluctant to shine too much light on that whole MIME type issue.
Birnam wood is come to Dunsinane
Opera 9 supports incremental rendering for XML, and Henri Sivonen is currently working on it for Gecko.
Simon Pieters
This is all very interesting. If nothing else it serves as a heads up; prior to yesterday I would have expected my sites to work if served as application/xhtml+xml. Now I am at least aware that they probably won't, and can take steps to make sure nothing nasty happens in the future. I will pass this on to colleagues as well. Now each time I write a site using XHTML-P
Thanks for your patient and detailed replies, Tommy.
Well ... Opera 9 is still in beta and if Henri is still working on it, then my statement is still correct ... technically.
Birnam wood is come to Dunsinane
I think this thread should be stickied, for all us XHTML-P'ers out there
Personal Portfolio
Paul O'B is the CSS god
Posting Permissions
Bookmarks