Head First HTML with CSS & XHTML 197
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.
choice between frames and CSS? (Score:2, Informative)
Amazon has it for $23.07 (Score:3, Informative)
Re:Amazon has it for $23.07 (Score:4, Informative)
Don't write XHTML - stick to HTML! (Score:1, Informative)
Or at least, don't write XHTML unless you really know what you're doing, and know to send real XHTML (application/xhtml+xml) to compliant browsers.)
Sending XHTML as text/html Considered Harmful [hixie.ch]. (Written by Ian Hickson, who's an editor of half a dozen CSS drafts, QA person for Mozilla, ex-QA for Opera, and nowadays works on 'HTML 5' (WHATWG web apps) for Google.)
Re:The simplest standards compliant webpage EVAR (Score:3, Informative)
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).
Re:HTML is passe (Score:5, Informative)
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.
Re:I still don't like CSS standards (Score:2, Informative)
I'm halfway through this book right now. (Score:4, Informative)
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.
Re:Alternative to innerHTML? (Score:2, Informative)
createNode and attachNode just like the old days :)
So what's the accepted DOM function that, given a string of markup, parses the markup to give me one or more nodes that I can attach?
Check out http://script.aculo.us/ [aculo.us] for a javascript class called Builder, works well.
The page you linked does not contain the word "Builder", and neither does the Prototype library linked from there. If it's part of the script.aculo.us library, I'm not in a position to evaluate that library as I write this comment. Besides, would it run nearly as fast as the browser's built-in markup parser, which I assume is used for handling the innerHTML property?
What you are doing is inserting a character data node into the DOM not element nodes.
If I were inserting character data instead of markup to be converted to element nodes, then I would use the innerText property, not the innerHTML property.
Re:HTML is passe (Score:4, Informative)
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 [ietf.org], 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.
Re:Alternative to innerHTML? (Score:3, Informative)
A string is not a node set. innerHTML just sticks some string in CDATA and plops on the DOM. I'm sure that browsers will try and stick it in the DOM but as you don't have to supple innerHTML a well formatted string, there are no guarantees. document.innerHTML('blah &b <lah> lalala&'); is valid javascript, but it certainly isn't valid XHTML.
Re:HTML is passe (Score:3, Informative)
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.
The b-is-deprecated myth (Score:3, Informative)
http://www.w3.org/TR/xhtml-modularization/abstrac
Re:Designing With Web Standards (Score:4, Informative)
But this book is for beginners. I just finished reading it. I didn't learn a whole lot but I did pick up a few things I had either never known or forgotten about. I may give this book to my wife who'd like to write some pages for herself. She's a complete neophyte. But I think this book is really geared to people like her. I believe one of the blurbs on the book talks about how refreshing it is to see a book that will start off new html/css authors with a foundation in standards. That I think is the real appeal of the book. It shows beginning authors how to use html/css using standards. And it does it in an entertaining and instructive way.
I wasn't particularly fond of Head First Java but I love Head First Servlets and JSP. The humor in this is quite a bit tamer but it's still a very good book for someone either just beginning html/css or looking for a basic review.
Re:More HTML books need to talk about CSS (Score:3, Informative)
Since I teach a course that includes XHTML and CSS, publishers often send me every web-related book they can think of, in the hopes I will adopt one as a text. Most are horrible. The number of vaidation errors in example code is astounding. I had always assumed that those who wrote books took some time to actually learn the material first. Apparently not.
The Head First book is the first one I have ever seen that treats the whole subject the "right" way, rather than adding in a few words about CSS as an afterthought to the 3rd edition.
Very good book. Highly recommended to anyone who wants to learn how to make web pages. The reviewer is correct, it's not a reference/professional book, but an excellent tutorial.
Re:Reviewerwho? (Score:3, Informative)
The basic hoops you have to jump through:
Once you've done that, try to validate it, and if it doesn't validate, fix the first error or two and try again. Don't get discouraged if you see 500 errors; many of those only show up because of previous errors that confused the validator. Just fix one at a time, and it probably won't take that long.
If you get in the habit of doing this on every page you write, you'll come to really appreciate how helpful the validator can be.
Re:IE is your roadblock (Score:2, Informative)
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.