Slashdot Mirror
Head First HTML with CSS & XHTML
Graeme Williams writes "In the past, I've written the sort of poorly-structured non-compliant web pages that can only be produced by a combination of laziness and confusion, so I'm an ideal test subject for Head First HTML with CSS & XHTML, an introduction to building web pages which focuses on compliance with the most recent HTML 4.01 standard and XHTML 1.0 standard. The book starts with the simplest of web pages, and builds from there to a solid foundation for writing simple well-structured web sites. It's clear and thorough, and will be effective both for the complete beginner and in bringing stale skills up to date." Read on for the rest of Graeme's review.
Head First HTML with CSS & XHTML
author
Elisabeth Freeman & Eric Freeman
pages
xxxv + 658
publisher
O'Reilly Media
rating
10
reviewer
Graeme Williams
ISBN
0-596-10197-X
summary
A clear, effective and readable explanation of standards-compliant HTML, XHTML and CSS
This is one of those cases where you can judge a book by its cover. In addition to the title and author, the cover of Head First HTML with CSS & HTML has seven tag lines, four photos and two drawings. One of the nuggets is, "A learner's guide to creating standards-based Web pages", which is a pretty good summary of the book and its intended audience.
Head First HTML is full of the sort of distractions that would normally make my skin crawl: people talking at me from the margins, mock conversations between inanimate objects (or in this case HTML tags), crosswords, quizzes and enough cute graphics to supply the kindergartens of a fair-sized city. It's clear that the authors realize that there might be some resistance to this style because they devote five pages of the introduction to explaining why they wrote the book this way – the summary of the summary is that novelty helps your brain learn. The example chapter you can download from the web site for the book is more than 50 pages, which might be enough for you to make up your own mind whether this works for you. My experience was that the method is so effective and the material so clearly presented that the issue disappeared for me after a chapter or two.
In the introduction, the authors also mention another goal: "a clean separation between the structure of your pages and the presentation of your pages". HTML or XHTML is used to provide the structure and content of a web page, and CSS (Cascading Style Sheets) are used to provide the style and layout. This means that the book doesn't include many HTML elements which are now discouraged or "deprecated", such as <B> for bold, <CENTER> for centered text, or <FONT> for specifying fonts within the web page. I guess the choice between frames and CSS might be classified as a religious one. In any case, this book is about CSS and doesn't mention frames except to note their omission in the appendix.
Most of the examples are based on a fictional coffee company called Starbuzz, and their trendy competitor, the Head First Lounge. It's a great framework for building up a web site from a few linked pages to a complete CSS layout. If you've never written a web page before, the book starts at the beginning, with the simplest web page followed by links from one page to another. If, like me, you've written a handful of web pages, reviewing the material will help focus on the essentials for a clean, compliant web page. All of the example HTML, CSS and accompanying images can be downloaded from the web site for the book, which also has the completed examples online, so you can quickly review them in your browser. If you're considering buying Head First HTML, the online examples are also a great way to see the scope of the book, from the simplest example to the most sophisticated.
There are a few prerequisites for getting the most out of Head First HTML. Adobe Photoshop Elements is used to show you how to prepare images for the web. As the book says, if you don't have it, you can download a free trial from Adobe, with the small quibble that this won't work if you've already run through your free trial before starting the book.
Understandably, Head First HTML doesn't tell you everything you might ever need to know about CSS. On the other hand, you learn a whole lot about using CSS both for appearance (such as colors and borders) and layout (positioning different parts of the page such as headers and sidebars). The book is particularly good at explaining at least some of the limitations of CSS, such as the different compromises of liquid, jello and frozen layouts. It's easily enough for you to be able to continue learning or experimentation on your own. With forgivable cuteness, the book also frequently mentions the availability of other O'Reilly publications with more information, such as HTML Pocket Reference and CSS Pocket Reference.
Similarly, the book gives a clear presentation of the different ways of setting text size, but doesn't provide the last word. If you're looking for Javascript to automatically size text based on screen resolution and browser width, you'll have to look elsewhere. In fact, Javascript is one of the ten things mentioned in the appendix, "The Top Ten Topics We Didn't Cover", leaving room for Head First Javascript to be published in 2006.
The last chapter provides a brief introduction to forms, including example designs both with and without tables. The goal of the chapter is to show you how to use CSS to style and layout forms, but you can't try out a form without something on a web server to process it, so the book's web site includes a simple-back end which will "process" (really just echo) the forms which are submitted to it.
Head First HTML deserves its score of 10, but that doesn't mean every word is perfect. I wasn't comfortable with the description of CSS borders, margin and padding until I'd gone back and re-read it. And it wasn't obvious to me that the background of a margin (such as a dashed margin) is the same as that of the content area it surrounds until I'd worked through some examples on my own. But that just underlines the fact that the book is so readable that I could tell when my understanding was slipping.
While Head First HTML never claims to be a reference, information is presented very clearly. If you forget the differences between HTML and XHTML, the book's excellent summary is easy to find, and includes a discussion of the W3C HTML and XHTML validator. That said, the index is short and idiosyncratic: there is a list of page references for the Q&A sections (under T for "There are no dumb questions") but transitional HTML is indexed only under "HTML, transitional", and jello, the layout, is found under "Design" but not "J" or "Layout".
I've said that I was initially very skeptical about the graphics-heavy Head First Labs house style. I'm pretty sure I've been thinking in prose all my life, but apparently verbal and graphical perception can be safely intermingled. I can't explain why, but this garden salad of words, pictures and diagrams of all kinds provides a easy-to-read and very effective introduction to a large amount of material."
You can purchase Head First HTML with CSS & XHTML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This is one of those cases where you can judge a book by its cover. In addition to the title and author, the cover of Head First HTML with CSS & HTML has seven tag lines, four photos and two drawings. One of the nuggets is, "A learner's guide to creating standards-based Web pages", which is a pretty good summary of the book and its intended audience.
Head First HTML is full of the sort of distractions that would normally make my skin crawl: people talking at me from the margins, mock conversations between inanimate objects (or in this case HTML tags), crosswords, quizzes and enough cute graphics to supply the kindergartens of a fair-sized city. It's clear that the authors realize that there might be some resistance to this style because they devote five pages of the introduction to explaining why they wrote the book this way – the summary of the summary is that novelty helps your brain learn. The example chapter you can download from the web site for the book is more than 50 pages, which might be enough for you to make up your own mind whether this works for you. My experience was that the method is so effective and the material so clearly presented that the issue disappeared for me after a chapter or two.
In the introduction, the authors also mention another goal: "a clean separation between the structure of your pages and the presentation of your pages". HTML or XHTML is used to provide the structure and content of a web page, and CSS (Cascading Style Sheets) are used to provide the style and layout. This means that the book doesn't include many HTML elements which are now discouraged or "deprecated", such as <B> for bold, <CENTER> for centered text, or <FONT> for specifying fonts within the web page. I guess the choice between frames and CSS might be classified as a religious one. In any case, this book is about CSS and doesn't mention frames except to note their omission in the appendix.
Most of the examples are based on a fictional coffee company called Starbuzz, and their trendy competitor, the Head First Lounge. It's a great framework for building up a web site from a few linked pages to a complete CSS layout. If you've never written a web page before, the book starts at the beginning, with the simplest web page followed by links from one page to another. If, like me, you've written a handful of web pages, reviewing the material will help focus on the essentials for a clean, compliant web page. All of the example HTML, CSS and accompanying images can be downloaded from the web site for the book, which also has the completed examples online, so you can quickly review them in your browser. If you're considering buying Head First HTML, the online examples are also a great way to see the scope of the book, from the simplest example to the most sophisticated.
There are a few prerequisites for getting the most out of Head First HTML. Adobe Photoshop Elements is used to show you how to prepare images for the web. As the book says, if you don't have it, you can download a free trial from Adobe, with the small quibble that this won't work if you've already run through your free trial before starting the book.
Understandably, Head First HTML doesn't tell you everything you might ever need to know about CSS. On the other hand, you learn a whole lot about using CSS both for appearance (such as colors and borders) and layout (positioning different parts of the page such as headers and sidebars). The book is particularly good at explaining at least some of the limitations of CSS, such as the different compromises of liquid, jello and frozen layouts. It's easily enough for you to be able to continue learning or experimentation on your own. With forgivable cuteness, the book also frequently mentions the availability of other O'Reilly publications with more information, such as HTML Pocket Reference and CSS Pocket Reference.
Similarly, the book gives a clear presentation of the different ways of setting text size, but doesn't provide the last word. If you're looking for Javascript to automatically size text based on screen resolution and browser width, you'll have to look elsewhere. In fact, Javascript is one of the ten things mentioned in the appendix, "The Top Ten Topics We Didn't Cover", leaving room for Head First Javascript to be published in 2006.
The last chapter provides a brief introduction to forms, including example designs both with and without tables. The goal of the chapter is to show you how to use CSS to style and layout forms, but you can't try out a form without something on a web server to process it, so the book's web site includes a simple-back end which will "process" (really just echo) the forms which are submitted to it.
Head First HTML deserves its score of 10, but that doesn't mean every word is perfect. I wasn't comfortable with the description of CSS borders, margin and padding until I'd gone back and re-read it. And it wasn't obvious to me that the background of a margin (such as a dashed margin) is the same as that of the content area it surrounds until I'd worked through some examples on my own. But that just underlines the fact that the book is so readable that I could tell when my understanding was slipping.
While Head First HTML never claims to be a reference, information is presented very clearly. If you forget the differences between HTML and XHTML, the book's excellent summary is easy to find, and includes a discussion of the W3C HTML and XHTML validator. That said, the index is short and idiosyncratic: there is a list of page references for the Q&A sections (under T for "There are no dumb questions") but transitional HTML is indexed only under "HTML, transitional", and jello, the layout, is found under "Design" but not "J" or "Layout".
I've said that I was initially very skeptical about the graphics-heavy Head First Labs house style. I'm pretty sure I've been thinking in prose all my life, but apparently verbal and graphical perception can be safely intermingled. I can't explain why, but this garden salad of words, pictures and diagrams of all kinds provides a easy-to-read and very effective introduction to a large amount of material."
You can purchase Head First HTML with CSS & XHTML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I'm actually being forced to take a class in introductory web design. The books for this class are fairly new, yes seem to be stuck in the HTML 3.x days, with font tags, bgcolor properties, and a particular emphasis on the 216 (215?) web-safe colors.
I wish books like this one were used instead. Teaching the right way the first time is so much easier than having to tell someone that everything they learned was wrong.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Can somebody say lawsuit?
As to the book itself, I looked at the sample chapter and it's in the random, jumpy style that marks the modern MTV generation. It has some appeal, but I think trying to get through a whole book laid out like that is going to cause headaches. Still, I plan to buy it, just to see if I can learn anything new.
GetOuttaMySpace - The Anti-Social Network
This book can never be any good! Everyone knows comes before !
While I haven't read this particular Head First book, I have nothing but praise for the rest of the series.
The 'Learner's Guide' is exactly right; they explain everything they do clearly, they make the examples and exercises fun and easy to understand, not only on what to do, but why to do it. The books are graphically appealing and funny (and it's not just nerd humor), which makes them easy to read, but at the same time they don't sacrifice information, or simplify it beyond understanding.
Sight unseen, I would recommend this book, the same way I do their other ones.
Amazon has it cheaper than BN. ($23.07 vs $27.96)
Expert Java EE Consulting
Skip the review. Read Zeldman's awesome Designing With Web Standards. It will change your life. At least until you read the next life changing book.
Zeldman is also teaming up with Eric Meyers, the CSS God for An Event Apart.
"You'll get nothing, and you'll like it!"
You are thinking of the semantic web, which is XML based; however, XHTML is not inherently semantic, just easily-parsed.
English is easier said than done.
In the past, I've written the sort of poorly-structured non-compliant web pages that can only be produced by a combination of laziness and confusion
Wait a minute, were you copying my style!?!
He who knows best knows how little he knows. - Thomas Jefferson
What version? The simplest HTML 4.01 document can omit the <html> tags entirely. The only required element that doesn't have optional start and end tags is the <title> element. Furthermore, if you don't care about browser compatibility, you can even use shorthand notation to reduce the document to:
The validator chokes on it, but I believe that's a bug in the validator, at least for Transitional (Strict requires at least one child for BODY, but Transitional doesn't).
Bogtha Bogtha Bogtha
That's probably because you design the whole thing, checking it regularly in IE, then when it's all done check it in Firefox and don't like what you see.
In reality, FF has way better adherence to CSS standards than IE does. IE is crap. Intentionally broken crap. 5 years outdated, full of holes crap.
Lose Weight and Feel Great with Isagenix
Designing With Web Standards by Jeffrey Zeldman.
And it's cheaper .
"Ask not what your country can do for you." --John F. Kennedy
Huh? There's not much difference between HTML and XHTML. The latter is essentially just the former converted to valid XM. You have to close your tags, but that's about it.
If you can't "harvest data" from HTML's <h1> tag, you're still not going to be able to harvest data from XHTML's <h1> tag.
A Government Is a Body of People, Usually Notably Ungoverned
Given that the market at the moment is trying to squeeze as much functionality out of existing technologies and the increasing use of new markup languages such as SVG and MathML, I would have thought that more and more books would start teaching XHTML/CSS.
XHTML will allow far better flexibility when adding in new functionality provided by new markup languages as well as better machine readability for the purposes of migrating pages at a later date. Tools to assist in developing syntactically valid XHTML pages are easily available and easy to use (such as Firefox's Validator tool as well as the old trusty http://validator.w3.org/), so the argument that novices may break XHTML pages by not writing valid code is not as potent as it once was.
The challenge now lies in teaching students to write semantically correct markup. This cannot be checked by a validator or any other machine tool, as semantically incorrect markup may still follow the rules of syntax. However, it can break a braille browser or a mobile device that degrades pages' layout for the purposes of displaying it on a small screen, rendering the information inaccessible to users of these devices.
XHTML's stricter syntax far more strongly encourages users to think in terms of content/presentation rather than just writing a blob of HTML to show a nicely formatted essay/blog/gallery. The more information is both syntactically and semantically correct, the more the web will be a friendly place for users of devices other than PCs, or users who are accessing the web from a device designed to aid a disability.
It is for these reasons, forward compatibility and accessibility, that I think that XHTML should start being taught. I always hear it argued, when I recommend XHTML to a would-be developer, that "XHTML is not understood" and "it breaks pages if used incorrectly". Well, help users to understand, and teach them to use it correctly.
I hate printers.
It's a shame that most people who code xhtml have no idea about the specs and create hideously invalid pages. It's like people don't care about character encoding and it can make site completely invalid very quickly. How many pages become invalid if I submit a ࣠to a form for preview?
People don't seem to understand the difference between comments and CDATA (think javascript code), almost no-one writes data into the DOM correctly with javascript (document.write() and innerHTML are wrong and makes a page no longer xhtml as the content is not written into the DOM.)
Hell I see people who can't even encode ampersands.
I like to ask them their views on html and xhtml. The correct answer isn;t to jump into bed with xhtml just because it is a buzz word, but to use the right code in the right situation. If your code isn't in a guaranteed xhtml safe environment use html (that is 95% of the time IMHO) - i've seem people putting xhtml code into pages that are written in html, and don't even have a docutype!
"In a time of universal deceit - telling the truth is a revolutionary act." - George Orwell
Yeah, right. We've been hearing about how we should all be using XHTML and XML for ages. And yet... the web is still running on HTML 4.01.
Now, I suppose you could blame Internet Explorer for not properly supporting XHTML (it treats it as XML and displays the DOM if you try and do it properly, serving XHTML as "text/html" is wrong and broken). I haven't actually checked to see if the new IE7 supports XHTML properly, but, even if it does, XHTML doesn't really solve anything. It doesn't make data mining any easier. It's just HTML with end tags required.
What's really interesting, IMHO, is CSS3 and XML. You can style XML documents with CSS, which means you could conceivably have a document that describes the contents of the page in a fairly "semantic" manner (I think someone just won Buzzword Bingo here) and then is styled based on CSS for proper display.
You can already do something like that with XSLT, but XSLT has never seemed to really catch on, possibly because it's fairly complicated. With XML and CSS, it uses essentially the exact same semantics that HTML and CSS do (other than having no defaults), and you can apply most of the same styling knowledge from using CSS with HTML to using CSS with XML. The Content Creation section of CSS3 offers some really interesting possibilities.
Of course, without Internet Explorer support, this is basically useless, but it's still something that's fun to play around with, if not practical. But it does mean that we're still going to be using an HTML-based web for the forseeable future.
You are in a maze of twisty little relative jumps, all alike.
Last time i checked, IE does NOT cope correctly with for example the ACID2-test [http://webstandards.org/act/acid2/test.html#top]. For example the default browser on the mac, Safari, is one of the few browsers that actually does.
I bought this book with the intention of reteaching myself the "right way" to do web design. I've used CSS for a few years now, but I've never gone the full 9 yards and completely separated all my markup from all my presentation. I always had the occasional deprecated HTML tag in there because it was what I was used to.
After seeing the impressive amount of control you get from moving away from tables and tags to nothing but XHTML and CSS I was ready to make the jump.
The first half of this book won't be anything new to most people, but in the 2nd half of the book I've never seen the box model, div layout, and css explained so clearly. It's made adjusting my web design skills much much easier.
Highly recommended.
ce n'est pas un Sig.
document.write() and innerHTML are wrong and makes a page no longer xhtml as the content is not written into the DOM.
As far as I can tell, the function of the innerHTML property is to 1. parse the string passed to it as a fragment of HTML or XHTML, 2. convert it to a properly structured subtree for insertion into a DOM, and 3. link it into the DOM under the specified element. If innerHTML is deprecated, then what's the proper way to call the browser's parser to turn a string containing a fragment of XHTML into a DOM node for insertion? Or do I have to write my own parser in JavaScript and reference it from each page, duplicating a function already built into the compiled browser using possibly slower interpreted code?
Choice between WHAT? I think you mean between CSS and tables. Or CSS+XHTML vs. Whatever HTML-like Syntax Works.
But really, there is no need to choose. I use the deprecated b tag all the time, because it is SIMPLE, love to use tables, because they WORK for displaying on various screen sizes, plus (gasp) deploy the font tag from time to time for quick prototypes. And, guess what? I also use CSS. Fact is, Firefox and IE support CSS alongside HTML elements. And so the standards.
I could care less about what is "deprecated" by W3C, as though they are going to come over and scold me, and as though I would care.
I had that book. It spends a lot of pages advocating why you should design with web standards and the history of bad web design, but it really doesn't provide reference information or many useful examples. The book is more about advocacy and "ranting" than a reference book, so keep that in mind.
I think that if you look a little closer, you'll find that the web isn't "running on" XHTML or HTML 4.01, but rather a bizarre concoction of tag soup that happens to make popular browsers behave a certain way.
Perhaps according to you, but not according to RFC 2854, which defines the text/html media type.
It doesn't.
It doesn't so long as it's a minority. When the overwhelming majority of the web uses XHTML, its draconian error handling that it inherits from XML will simplify browsers considerably. This has already happened to a certain extent with the mobile web.
That's completely wrong. Sure, you could make up your own semantics that you associate with the element types you use in your ad-hoc XML format, but nobody else would know about those semantics. That's why you use a common, specified XML format... like... XHTML, where the semantics are understood.
XML isn't a super-format that magically gives you semantics. XML solves the syntax problem and stays well away from the semantics problem. Semantics are addressed at a higher level.
Generic XML has essentially no semantics whatsoever. It certainly doesn't have the same semantics as HTML.
Bogtha Bogtha Bogtha
But really, there is no need to choose. I use the deprecated b tag all the time, because it is SIMPLE, love to use tables, because they WORK for displaying on various screen sizes, plus (gasp) deploy the font tag from time to time for quick prototypes
I agree. They can take my <B> tag when they pry it from my cold, dead text editor.
Really... a few nested tables work just FINE. And, if you happen to build e-commerce sites catering to a large cross-section of humanity, you'll find yourself serving pages up to people with a four-versions-ago copy of the AOL client, or Netscape 4.1, etc. They're still out there. Nice as some fancy-pants AJAX-ish stuff is for portally things or specific audiences, even some fundamental CSS things are beyond a lot of visitors' platforms, depending on your demographics.
Don't disappoint your bird dog. Go to the range.
In my experience, the main difference between the Head First series of books and other lame publishers who are trying to be cute to increase sales is that the Head First approach includes these graphics for specific reasons to enhance the ability of the human brain, which evolution has hard-wired to discard almost all information that it deems not immediately useful to your continued survival (which is just about everything the clutters our lives in daily modern life), to understand and retain information that would otherwise require multiple readings and study sessions to convince (i.e. force) your brain to understand that you really do want to remember this stuff. The head first approach is based upon extensive research into the neurobiology of learning done by Academia over the past several decades in an attempt to teach you the information that you want to learn (you bought the book after all so you presumably want to learn more about the topics that the book purports to teach) and help you retain it with the minimum amount of re-reading, studying, and general frustration. If you don't like this approach then by all means buy the traditional textbook style presentation instead...its your money after all, but I wanted to point out that the Head First style is not trying to be cutesy or funny just for the hell of it but to help you learn the material better and for that they deserve some credit.
The key to understanding the market for techincal books is to realize that not everyone's time is equally valuable. You are quite correct in your assertion that all of the raw information in the book can be found on the Web for free with a few search sessions and some digging through the trash...and the web is full of bad advice and just plain wrong information, especially when it comes to web design and development where many people have conflicting opinions which they recite as factual information. That having been said the value in the technical book comes in the order and presentation of the materials, the expert (usually) peer reviewed suggestions and best practices, and the aggregation of various sources into one coherent work. All of this could be learned without spending you hard earned money by doing enough searching, digging, and reading on the web, but at the end of the day who do you want to trust....user99 the phat html h4x0|2s...or the somewhat more credible authors of these books...that and the main point which was how much is your time worth?
So if the relevant specification says that it's okay, then it's a little disingenuous to state unconditionally that it's wrong then, isn't it?
text/html means whatever the text/html specification says it means. That includes XHTML 1.0 following the compatibility profile.
That isn't the only advantage of XHTML, but you are right in saying there's little point in choosing XHTML over HTML if all you are going to do is serve it as text/html.
Despite allusions to the contrary in the specification, XML Schemas don't express any semantics either. They define structure. It's all very well knowing how a particular document type is meant to be arranged, but that doesn't tell you what it all means.
Key words here: "known other schemas". At some point it still comes down to the fact that the semantics have to be defined by a human-read specification, and a program has to be explicitly designed to take advantage of those semantics. If you are doing that, you aren't writing generic XML, you're just using a mechanism to mix-and-match existing semantics in existing languages - like XHTML - to produce a frankenstein document.
That's not to say it won't be useful, but the idea that you can just write arbitrary XML documents and have them understood is simply not the case. It still comes back to the rest of the world agreeing upon particular semantics for particular languages.
Of course it's more meaningful. The meaning of the element types and attributes are described in the XHTML/HTML specifications, and those semantics are hard-coded into many existing, deployed user-agents. Given "a random XML document" that you've just made up, there's no specification and even if you wrote one, it wouldn't matter because no software would understand it.
You mean element types, not "tags". The semantics of tags are completely unambiguous across all XML languages - they mean "an element starts here". And your argument boils down to "XHTML has limited semantics, therefore it's equivalent to having no semantics", which makes no sense. Limited semantics are still better than none.
Bogtha Bogtha Bogtha
is not deprecated. Everyone thinks it is for some reason.t _modules.html#s_presentationmodule
http://www.w3.org/TR/xhtml-modularization/abstrac
Of course, without Internet Explorer support, this is basically useless,
And that's a myth.
I run a website. Sections of it rely on CSS2 and don't work in IE. Instead of writing a workaround, I redirect IE users to a page that explains the problem in a few words, and gives them a link to try and look at the page anyways (this is mostly for Opera users identifying as IE).
Despite all the faked statistics claiming IE has a market share of 90%, the browser distribution on my site clearly favors Firefox (which I link to on the above-mentioned page) with almost 50%. IE is a clear second with about 40%, and the rest is Opera, Konqueror, Safari.
If I can do that to my visitors, imagine what would happen if a few major websites would do that, or something a little less radical, i.e. offering a "reduced features" version for IE users, with a box explaining the problem and pointing them to alternative browsers. My guess is that you'd see the same effect. Installing Firefox on windos is a few clicks, and a lot of people will do it if it means having one more cute picture.
Assorted stuff I do sometimes: Lemuria.org
The harm comes from doing it incorrectly, not the fact that you are doing it at all.
The point is that doing Appendix C "correctly" may prove to be more work than just sniffing Accept:.
you don't necessarily have to have dynamic content to do it. Apache MultiViews handles it without needing any scripting language, you just put 'foo.html' and 'foo.xhtml' into the same directory and link to 'foo'.
And then you have to 1. try to persuade your host to turn on Options MultiViews or .var files or both, which may require dealing with seemingly impenetrable layers of red tape, and 2. generate both XHTML 1.0 and HTML 4.01 and upload them to the server, taking up twice the space in the 10 MB that your ISP, university, or free host allots you.
You still haven't addressed the differences in CSS semantics and DOM semantics between HTML 4.01 and XHTML 1.0, and you still haven't addressed the point of using XHTML 1.1 or newer. Until Microsoft Internet Explorer supports XHTML without the Appendix C hack, what's the advantage of valid XHTML 1.0 over valid HTML 4.01?
Look at the spec for XHTML 1.0 Strict. It specifically allows text/html.
Any XHTML 1.0 Appendix C document sent with the media type text/html may be written in XHTML, but it won't be parsed as XHTML. Reason: If the document is sent as text/html then it will always be interpreted as SGML. If the document is sent as application/xhtml+xml then it will always be interpreted as XML.
The hard part is that the semantics of HTML DOM and CSS differ between the SGML (i.e. HTML 4.01) and XML (i.e. XHTML 1.0) embeddings. Do you claim that all web developers should design their pages to be compatible with both the HTML 4.01 DOM and the XHTML 1.0 DOM, and to be compatible with both the HTML rules for CSS and the XHTML rules for CSS?
Besides, Strict is currently less functional than Transitional because Strict lacks the value attribute of the li element, which is important for starting an ordered list at any value other than 1. The fact that the first track of a CD is numbered 13 is content, not presentation.