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&quot, 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.

Comments

More HTML books need to talk about CSS

[VGPowerlord]

I really hate it when I see an HTML book that teaches things that have been deprecated in modern HTML.

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.

Re:More HTML books need to talk about CSS

[MikeFM]

I agree. I work quite a bit with students who've just been taught HTML by their schools and they really are taught nothing about CSS. These are comp sci and graphic arts students for which web developing is a major job skill and they know next to nothing about CSS. They certainly aren't being taught to do anything advanced and most still use out-dated HTML when CSS would work better. A lot of things I do all the time they simply think you can't do. Pretty limiting.

Re:More HTML books need to talk about CSS

[a803redman]

CSS is great unless any of your viewers are using IE.

Re:More HTML books need to talk about CSS

[CRCulver]

CSS handles most CSS fine and has done so for years and years now. It's entirely FUD that you can't use CSS if you want to target IE users. There are some notorious CSS bugs in IE (although many have been fixed in the IE7 betas), but not everyone has to use these portions of CSS, and in any event there are easy workarounds.

Re:More HTML books need to talk about CSS

[Rayooz]

HTML works very well in HTML, too, although I've found that Java seems to have trouble with Java ... so watch out for that.

Re:More HTML books need to talk about CSS

[MikeFM]

If you want to do anything besides change your font color with CSS then IE has severe bugs. It certainly makes it hard to place blocks in the right places and at times impossible to get the same effect in IE that you can in Firefox or Safari. About the best you can do is find a workable half-assed solution for IE that leaves 70% of your site's users unable to experience the site in the most effective way. IE7 does seem to fix some of the bugs but not all of them which leaves me having to support yet another half-assed variant as IE7 once again isn't standards complaint in even the important elements of CSS2 but also doesn't render pages the way IE6 does. That'd be less of a problem if they'd release IE7 for older versions of Windows but as they don't plan to that means we'll be supporting IE6 for years too.

No work around is easy. On a site with 50 different elements if it takes me ten minutes per element to figure out a work around I just spent 500 minutes making the site work in IE. That's pretty much a whole work day. If I have to do that for IE6 and IE7 now that means two work days. That is best case scenario too. Now and then I find an issue with IE that in itself takes me an entire day to work around. I'd say that for every website I produce I spend around a week just finding issues with non compliant browsers and finding work arounds. So figure it costs about $1200 per website to fix these problems. That is a lot of money when you figure I produce a dozen or more websites a year. Let's just say that in my work alone $15,000 a year is spent fixing problems with IE and that still doesn't make the websites look as good in IE as they do in Safari and Firefox. IE nearly doubles the amount of time it takes me to make a static website.

Re:More HTML books need to talk about CSS

[b4k3d b34nz]

Like any profession, it's easy to start out doing something the easy way because you don't know any better. Unfortunately, we can trace a lot of the reason that people don't do it the right way to their formal education. Like you said, pretty much everything the newbies are learning is old hat or deprecated.

My alma mater teaches how to "write HTML" using Dreamweaver, along with the concepts of "styles", which is really the lame .style1, .style2 font effect crap that DW pulls. Basically, nobody comes out of those classes knowing anything useful--it's pretty much just learning how to mock up a cheesy webpage that looks like someone took it dumpster diving.

I think professors should be required to keep up with the technology. It would be a good idea for universities to hire more adjunct professors that have a job in the real world, instead of the hacks that still use HTML 3.2 because they don't know any better and haven't kept up with professional techniques such as templating, CSS, etc.

I still don't understand the obsession with 216 web-safe colors. I can't think of the last time I even saw 216 colors in anyone's house, much less my server logs. It seems that the people writing those books just copied a whole bunch of articles they printed off the internet 5 years ago and tried to compile them into a book, rather than thinking for themselves that it doesn't make sense.

This book is probably a good book, judging from its description, and that it's a Head First book. The others I've read in the series were wonderful.

Ok, done with the rant.

Re:More HTML books need to talk about CSS

[kimvette]

I really hate it when I see an HTML book that teaches things that have been deprecated in modern HTML.

Deprecated HTML elements (and browser sniffing) will be around for as long as Microsoft refuses to fix MSIE. This includes MSIE 7.0.

Re:More HTML books need to talk about CSS

[gregbaker]

seem to be stuck in the HTML 3.x days

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:More HTML books need to talk about CSS

[juiceCake]

I just finished this site http://www.adrenalineonline.net using CSS (for type and layout) and it seems to work just wonderfully. In IE 6.x (Windows) that is.

That said, it's probably a disaster for the one person who visited with IE5.

Re:More HTML books need to talk about CSS

[kchrist]

Deprecated HTML will be around, but that's no reason to continue teaching it. Whether you're a teacher or an author, the focus should be on up-to-date standards. I'm not talking about pure-CSS layouts necessarily -- you do want to be able to teach about backward compatibility -- but there's no excuse for including font tags and the like.

Re:More HTML books need to talk about CSS

[MooUK]

If you make many websites, you will quickly learn which (usually very simple) workarounds are necessary where. And hence all the fancy calculating you've done above is irrelevant.

Re:More HTML books need to talk about CSS

[Gnight]

Nice design; it renders great on FF1.5 (linux). Although you might consider displaying the links with an underline (or something) to distinguish them as links. Right now I can't tell what's a link and what's not.

Re:More HTML books need to talk about CSS

[Anonymous Brave Guy]

On a site with 50 different elements if it takes me ten minutes per element to figure out a work around

...then you're in the wrong line of work.

Seriously, we all know that IE's handling of CSS is buggy as hell, and there are plenty of bugs in other browsers, too. However, the vast majority of problems come down to the same half-dozen or so "frequent offenders", and the circumstances when they arise and the workarounds for them are widely known and readily available for the price of a search engine query. If it takes you more than a few minutes to patch up the CSS for a sensibly-designed site to make it compatible with the vast majority of browsers in use today, then you need to spend less time slagging off other people's software on Slashdot and more time reading introductory tutorials on browser compatibility.

And yes, I have done the CSS for several moderately large web sites, and yes, they do all display correctly on all recent versions of all major browsers.

Re:More HTML books need to talk about CSS

[Anonymous Coward]

Kheerrist... just use HTML 4, IE is only very slightly broken at HTML 4. CSS is nice and all but don't bother unless you really have to. Just because a standard gets updated doesn't mean you have to use the latest.

Re:More HTML books need to talk about CSS

[MikeFM]

It still takes time to find them and implement your workarounds so yes it still takes time. Most developers simplify the process by just not doing some things that are possible in other browsers. That is a pretty crappy way of working. It leaves you designing to the lowest standard. If you do something advanced it is not especially easy to make it look decent in IE. There are more workarounds needed and the workarounds become more involved.

So if you create blah pages then yes it won't take much time to do a couple workarounds. If you create something engaging then it can take much longer regardless of your experience. I've been making websites since people were connecting with 2400 baud modems. It still takes time to do it well despite my experience.

Re:More HTML books need to talk about CSS

[legirons]

"IE7 also doesn't render pages the way IE6 does."

Well that's a confusing situation, isn't it? For years, the MS geeks have been telling us that way IE6 renders things is the de facto standard on the internet. So if IE7 doesn't follow that standard, then what? Is IE7 non-standard if you're a Microsoft Certified Astroturf Marketer? Or is IE7 the new de-facto standard, and IE6 is now non-"standards"-compliant?

How will the "design your site for IE and to hell with everything else" people cope with this transition? Do they have to start using Flash?

And what about IE5 -- I seem to remember a lot of people on slashdot coding exclusively for that because "in the real world, nobody will be using anything other than IE5". If that now has less of a market share than some of the weirder versions of unknown browsers, have those people recoded their websites every couple of years, or do they just accept that they look broken in "other" browsers such as IE6 and IE7?

Re:More HTML books need to talk about CSS

[kimvette]

Yes, you're absolutely right about tags; however there are many instances where MSIE will absolutely refuse to align things correctly, forcing one to resort to table layouts with align=foo height=n width=x type of syntax, and in some instances one's hand is forced to throw an hspace and vspace on an image because although Firefox, Konqueror, Safari, Opera, Epiphany, Netscape, and so forth respect the CSS directives, MSIE will INSIST on padding the image, breaking your layout for the majority of users.

The fact that MSIE flat-out refuses to fix MSIE is unforgivable. Fuck Microsoft.

Re:More HTML books need to talk about CSS

[juiceCake]

Your note about links is noted. I don't want to get into a marketing versus usability versus visuals debate but I am aware of these issues. My point is, the statement about CSS being pretty well useless in regard to Explorer is clearly overly simplistic. I, and others I work with, have found it very useful.

This is not, however, to say we haven't found it grossly frustrating in some cases and that in some ways, the quirks of Explorer can affect the design of a site.

Re:More HTML books need to talk about CSS

[Anonymous Coward]

But I've heard that IE fails in IE...

The simplest standards compliant webpage EVAR

[Anonymous Coward]

<html>
</html>

Re:The simplest standards compliant webpage EVAR

[terwey]

*sigh* if you would READ the minimum for a compliant webpage you would know it contains a DOCTYPE, then the etc crap...

Re:The simplest standards compliant webpage EVAR

[The Snowman]

Actually, the only required tag is . Everything else is optional, and implied. Note that this is only in HTML 4.01, I think the major structural tags () are required in XHTML. Also, the declaration is technically required for SGML derivatives, but not strictly part of the HTML/XHTML language.

Re:The simplest standards compliant webpage EVAR

[Bogtha]

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:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<title/He llo, World!/

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).

I still don't like CSS standards

[Thaidog]

Talk about non-compliant. It always looks good on IE and then fscks up on every other brower's rendering engine.

Re:I still don't like CSS standards

[Potato Battery]

Really? So far, in my admittedly limited trials, I've found IE to be the browser I have the most compliance issues with. I guess it depends on what is being done.

Re:I still don't like CSS standards

[b3x]

or more accurately, it looks great on the others (opera and mozilla) and looks fsckd up on IE. in my experience IE's padding and margin implementations are often the problem

Re:I still don't like CSS standards

[DigitalRaptor]

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.

Re:I still don't like CSS standards

[zqad]

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.

Re:I still don't like CSS standards

[Irish_Samurai]

Well, part of the reason that alot of layouts are broken is because Mozilla and its Ilk put the remainder margin space (if you give a non equally divisible value) on the bottom of an element. IE puts it on the top. This may not seem like much, but it will wreak havoc on your layouts when your Margins collapse.

I'm not sure placement of the remainder is layed out in the standard, but I may be wrong.

Oh, and you should build for Mozilla and then fix IE, it's hella easier to do it that way than the other way around.

Re:I still don't like CSS standards

[Thaidog]

As noted with other posters the problem in not really IE but that if you design it ni mind for IE... or deisgn it in mind for FireFox you get mixexd results on other browsers... I'm guessing this is from an incorrectly following the standard, a poorly written standard or poorly implemented code. Maybe all 3.

Re:I still don't like CSS standards

[TubeSteak]

The ACID test only checks to see if your browser is compliant with... wait for it... the ACID test.

It can't possibly test for everything and it doesn't.

It's a nice reference point, but that's all it is, a reference.

Re:I still don't like CSS standards

[Fallingcow]

It's probably the box model. The one for IE isn't the same one that's used by every other browser in existance (the standard). In IE the total width and height of an element is inclusive of the border and margin (padding too? I don't recall). In the normal box model, these things are in addition to the width and height. In other words, in IE the height and width are the total size of an element, while by the standard they should be the height and width of the content area only.

So this:

#blah {
width: 100px;
height: 100px;
margin: 10px;
border: 5px;
}

gives you an element with a width and height of 100px in the IE box model, and a width and height of 115px ([width|height] + [margin] + [border]) in the standard box model.

So, if you code just about anything involving any static heights and widths for either the standard or for IE and don't include some work-arounds, yeah, it'll look different in one than it does in the other.

Re:I still don't like CSS standards

[Fallingcow]

Oops, mistake.

That code will give you height and width dimensions of 130px in a standards-compliant browser, not 115.

Re:I still don't like CSS standards

[Bogtha]

That problem was fixed when Microsoft released Internet Explorer 6.0 in 2001. Keep up. If you're still experiencing that problem, then it's because you are kicking Internet Explorer into "quirks mode".

Re:I still don't like CSS standards

[b4k3d b34nz]

The other big difference is IE's box model deciding to expand elements that have padding and width defined. People who code just for IE always complain that everyone else renders it wrong when they run into this.

Re:I still don't like CSS standards

[Fallingcow]

Ah, yeah, I didn't think to mention that part.

I just meant that if the person who was complaining about this was consistently having problems with IE and Firefox/Opera not displaying things the same way, it was probably the box model issue. And yeah, it'd have to be kicked into quirks mode for that to happen. Then again, I bet there are plenty of people working on web sites out there who don't even know what quirks mode is, let alone how to avoid falling in to it.

Thanks for the correction, that is an important bit of info.

Uh-oh!

[Billosaur]

Most of the examples are based on a fictional coffee company called Starbuzz

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.

Re:Uh-oh!

[kelzer]

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.

That's what I thought, too, until I read the preface to Head First Design Patterns. Turns out that the pictures, humor, etc., have actually been proven to improve learning and retention.

Re:Uh-oh!

[twbecker]

No way. I own both Head First Java and Head First Design Patterns, and I can tell you that the format rocks. It keeps you interested with pictures, funny examples and an edgy writing style. I enjoy reading technical books in general (sad I know), but I still prefer the HF approach to even a well written traditional style book.

Re:Uh-oh!

[Excelsior]

Turns out that the pictures, humor, etc., have actually been proven to improve learning and retention.

As someone who has read several in the "Head First" series, this is definitely true in my experience. Most books are designed to cover a subject with little emphasis on teaching it. Head First books are designed specifically to teach you, and they go to great effort to do so. Think about it: do you retain more per hour spent watching the History Channel, or reading a dry all-text history text-book? Remember, the book can take dozens of hours to read. The text-book may provide more complete content, but that doesn't matter much if you've forgotten much of it within a few months.

You will remember what a Head First book teaches you, and you won't need the book as a reference like most text-books.

If the grandparent wants to stick to all-text, old-world books, he can go right ahead. But he should try a "Head First" book before he criticizes it.

As for his reference to the MTV generation, that is simply misplaced. Children and young adults have despised reading boring text books since the invention of the alphabet. Don't let nostalgia The difference is that today they cannot live a high quality life without knowledge. I, for one, commend innovators like Bert Bates and Kathy Sierra for making sure that there are better options for learning that is rewarding for people of nearly all ages.

Re:Uh-oh!

[Anonymous Coward]

Yeah, well I had Head First Design Patterns and learned nothing from it. I couldn't get into it. I couldn't get into the flow of reading and absorbing. I suspect a lot of other geeks like me would feel the same way. It was like watching MTV. I have the original Design Patterns now and I'm loving it.

Re:Uh-oh!

[arodland]

That reminds me of Why's (Poignant) Guide to Ruby, which I thought was pretty amusing... but then again I didn't really like the book, and I didn't learn anything about Ruby; I just know a lot more about Starmonkeys, cartoon foxes, and why addiction is like Pokemon.

Re:Uh-oh!

[Anonymous Coward]

Turns out that the pictures, humor, etc., have actually been proven to improve learning and retention.
I second that. I first read Head First Design Patterns in a few days and then slowly consumed the Design Patterns book of Gamma et al. over a few weeks and I feel that made it much easier for me to see the whole Design Pattern picture.

Re:Uh-oh!

[JulesLt]

Nice distinction / emphasis - I think that's an issue with many software development books - that they try and pitch themselves somewhere between the two. I've got a large number of books that I keep for reference, which are bloated by beginners training sections - basic how to's on configuration, walking through the interface / command line, what is a SELECT or INSERT - stuff you will genuinely only need to learn ONCE. From a learning point of view, they're often poor, because they will then be structured as references - i.e. everything to do with collections will be in one chapter, exception handling in another, meaning that each chapter has to follow a beginners to advanced curve, meaning it can never really focus on one audience.

HTML is passe

[ravee]

HTML has got serious faults - the major one being the softwares unable to harvest the data inteligently from the web page created using HTML. This was IMHO why a new standard (much more strict) based on XML was developed which is called XHTML.

I think any book that teaches CSS and XHTML more than HTML will be widely embraced by the programming community.

Re:HTML is passe

[hunterx11]

You are thinking of the semantic web, which is XML based; however, XHTML is not inherently semantic, just easily-parsed.

Re:HTML is passe

[Arandir]

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.

Re:HTML is passe

[Freexe]

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!

Re:HTML is passe

[Freexe]

it seems slashdot can't handle my foreign character :) and displays ã instead.

(/s/docutype/doctype)

Re:HTML is passe

[_xeno_]

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:HTML is passe

[Bogtha]

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.

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.

serving XHTML as "text/html" is wrong

Perhaps according to you, but not according to RFC 2854, which defines the text/html media type.

I haven't actually checked to see if the new IE7 supports XHTML properly

It doesn't.

XHTML doesn't really solve anything.

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.

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

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.

With XML and CSS, it uses essentially the exact same semantics that HTML and CSS do

Generic XML has essentially no semantics whatsoever. It certainly doesn't have the same semantics as HTML.

Re:HTML is passe

[_xeno_]

Perhaps according to you, but not according to RFC 2854, which defines the text/html media type.

Actually, they say that the XHTML 1.0 mappings to "tag soup" can be marked as "text/html" but those markings are horrible anyway (and, best of all, invalid HTML 4.01). Calling XHTML "text/html" is still essentially broken. It's supposed to allow XHTML to be viewed with browsers that don't support XHTML, but it essentially removes the only advantage of XHTML - syntax checking.

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.

It's always fun to take an "XHTML 1.0 site" and run it through an XML parser, see how far it gets before bombing. The "draconian error handling" essentially guarentees that it'll never take off, or even if it does, that most browsers will start allowing worse and worse XHTML.

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

You do know that there are more XML schemas out there than just XHTML, right? There's no reason why you can't simply include xsi:schemaLocation and explain exactly what your XML contains. That's the entire point behind XML schemas. Theoretically, you can import various other schemas, so even if your site uses some custom XML markup, your schema can reference known other schemas and still make the data semantically meaningful.

However, suggesting that XHTML is magically more meaningful than a random XML document when it comes to semantics is just laughable. If you're trying to look at just the text, HTML offers various semantic meanings for the various tags. But if you want to go any further, like recognizing certain portions as addresses, XHTML offers no help. <div class="zipcode">1234</div> isn't any more semantically useful than <zipcode>1234</zipcode> - both require you to know the design of the specific document to be helpful.

Re:HTML is passe

[robmv]

then do what is recommended on the w3 FAQ

Re:HTML is passe

[gaspar ilom]

This issue is long solved: developers should encode their data semantically using XML.

Doing so makes it *trivial* to output your data, formatted however you want, as long as it is a something that any current or near-future browser will understand.

In their raw XML data, developers can use standard HTML for markup, when necessary -- or any conventions they want, really -- as long as they realize this markup is not necessarilly what they have to send to the browser.

Take your pick: you can do this dynamically, every time a user hits a page -- or you can pre-render static files. Using the same XML data file(s):

• XML + XSL ==> XHTML
• XML + XSL ==> XHTML "2.0"
• XML + XSL ==> HTML 4.01
• XML + XSL ==> HTML 5.0?

...And, of course, the raw-data, itself, can be filtered or converted at any future point:

• XML + XSL ==> XML, and this output can be fed-back into any of the operations above.

Someone tell me: Where's the "problem"???

Re:HTML is passe

[rodentia]

You can already do something like that with XSLT, but XSLT has never seemed to really catch on, possibly because it's fairly complicated.

Huh?! I've been working in XSL almost exclusively for several years now. It's used widely, in my experience. It is not particularly complicated, just not the kind of complication you are used to.

Re:HTML is passe

[Bogtha]

Actually, they say that the XHTML 1.0 mappings to "tag soup" can be marked as "text/html"

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?

Calling XHTML "text/html" is still essentially broken.

text/html means whatever the text/html specification says it means. That includes XHTML 1.0 following the compatibility profile.

it essentially removes the only advantage of XHTML - syntax checking.

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.

You do know that there are more XML schemas out there than just XHTML, right? There's no reason why you can't simply include xsi:schemaLocation and explain exactly what your XML contains.

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.

Theoretically, you can import various other schemas, so even if your site uses some custom XML markup, your schema can reference known other schemas and still make the data semantically meaningful.

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.

However, suggesting that XHTML is magically more meaningful than a random XML document when it comes to semantics is just laughable.

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.

If you're trying to look at just the text, HTML offers various semantic meanings for the various tags. But if you want to go any further, like recognizing certain portions as addresses, XHTML offers no help.

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.

Re:HTML is passe

[kfg]

. . .you could conceivably have a document that describes the contents of the page in a fairly "semantic" manner. . .

This Be The Verse

They fuck you up, your mum and dad.
They may not mean to, but they do.
They fill you with the faults they had
And add some extra, just for you.

But they were fucked up in their turn
By fools in old-style hats and coats,
Who half the time were soppy-stern
And half at one another's throats.

Man hands on misery to man.
It deepens like a coastal shelf.
Get out as early as you can,
And don't have any kids yourself.

-Philip Larkin

In exactly what manner do you believe the above could have its semantics and selfdescriptiveness improved by the edition of editorial tags?

KFG

Re:HTML is passe

[_xeno_]

I dunno, stuff like <verse>, <title>, and perhaps most useful, <author> - keep in mind we're talking about computerized semantics, not human readability.

The "semantic web" already runs mostly on magic - theoretically, people mark up sections of their document as having certain meanings (like an author) and then the "semantic browser" picks up on those. In this case, it might pick up on the author and allow searching for other stuff by the same author. Realistically, who is going to bother tagging their document by hand?

What's really more useful with XML and CSS is just making things clearer internally, so instead of doing something like <div class="title">, <div class="verse">, and so on, you'd just do <title>, <verse>, and so on. One of the main things CSS has done is made it so that more and more complicated webpages are becoming a mesh of <div>s and <span>s, making any semantic meaning that HTML has totally meaningless. (You gotta love <span class="bold"> over <b> as if that's somehow an improvement.)

Re:HTML is passe

[Tom]

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.

Re:HTML is passe

[kfg]

. . .perhaps most useful, - keep in mind we're talking about computerized semantics, not human readability.

And of what value is it to me that the computer knows that Philip Larkin is the author? I already know that because the content is semantic and selfdescriptive when used in conjuction with intelligence.

. . .it might pick up on the author and allow searching for other stuff by the same author.

Because searching on "Philip Larkin" doesn't work?

Realistically, who is going to bother tagging their document by hand?

The same anal retentive assholes who thought the whole thing was a good idea in the first place.

. . .making any semantic meaning that HTML has totally meaningless.

Again, who cares? The language already carries semantic meaning to an intelligence and I as yet cannot find any reason for the computer to know about such things.

grep, find, Google, they already work. Arrange your content intelligently and an intelligence will understand it and find what it's looking for just fine.

KFG

Re:HTML is passe

[_xeno_]

That was kinda my point originally, XHTML isn't going to replace HTML because XHTML offers nothing. (It certainly doesn't offer any form of semantic markup.)

What's interesting is more of creating your own "markup language" and using CSS to explain to the browser how it looks like. It's not really that much more helpful to the computer, but it can make the actual markup easier to read. So instead of having a page full of <div class="comment">, you can have <comment>, making the markup more understandable.

It won't be more useful outside of keeping the backend code more readable, but - meh. It's still kinda cool, and has interesting possibilities.

Re:HTML is passe

[kfg]

What's interesting is more of creating your own "markup language" and using CSS to explain to the browser how it looks like.

So, a standardless "standard" that clutters up the pipe explaining what the "standard" is to the browser for each and every webpage.

Yeah, that's a good idea.

While we're at it why don't we have everybody just write their own plugins as well?

It's still kinda cool

Many toys are cool; and useless.

KFG

Re:HTML is passe

[Some Bitch]

. . .it might pick up on the author and allow searching for other stuff by the same author.

Because searching on "Philip Larkin" doesn't work?

Not well enough, no (IMNSHO of course). I might want to be able to search only for things where Philip Larkin is identified as the author rather than getting pages about Philip Larkin. I might want to be able to retrieve a poem by searching for a line contained within a poem and only get back pages containing the poem rather than discussion of the poem. It's blue skies stuff and will probably require more standards adherence than we are ever likely to see but the current shotgun approach to searching is only "good enough" rather than "good" (even if you understand how to use a search engine properly which most people don't).

Re:HTML is passe

[rainman_bc]

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.

Uhm, doesn't that depend on whether you use strict or transitional?

IMO you're really dumbing down the standard if you're saying that's all it is.

Re:HTML is passe

[kfg]

And what makes you think they will understand, or even care about, tagging for "semantics"?

get back pages containing the poem rather than discussion of the poem. . .

What is the "no discussion" tag?

KFG

Re:HTML is passe

[jc42]

And slashdot screwed up your second comment, too. ;-)

Meanwhile, I note that slashdot sends out its pages with <meta ... charset=iso-8859-1"> in the header. So the mangling of that '£' is especially strange. Being in the UK, I'd guess that your default charset is also 8859-1, so there really shouldn't have been a problem. Let's see if my use of the pound symboll gets mangled similarly.

A few days ago, we had a bit of a discussion of the Chinese google. There were a few messages where it would have been very useful to include some Chinese characters. For example, in explaining the difference between the spellings "Tiananmen" and "Tienanmen", which correspond to slightly different Chinese text.

You'd think that by now we'd be able to include all the different UniCode charsets in a text list this. Different slashdot contributors are going to have different charsets, and I don't see anything in this "Post Comment" page that lets me specify a charset.

I wonder if there's a tag in XHTML that overrides the document's charset declaration, and declares a different charset for a section. I haven't read of one, but then I don't know all of XHTML. There could very well be an elegant solution to this that would allow the inclusion of a fragment of Chinese or Arabic or Mongolian or Mayan or whatever.

OTOH, slashdot does seriously restrict the HTML that is allowed. I can see the list a few lines lower. Unless you can name a new charset in a <div> tag, there's probably no way to Do It Right.

Re:HTML is passe

[Anonymous Coward]

How do you indicate a document's title using CSS with XML?

In other words, what's the equivalent to the HTML element?

Re:HTML is passe

[Anonymous Coward]

Foo, that should have said the "HTML element".

Re:HTML is passe

[legirons]

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.

Well Google Mail offers a "reduced features" version to Konqueror users, and links to a page suggesting that it will work better on supported browsers such as IE and Mozilla. Don't think that's exactly what you meant though ;-)

Re:HTML is passe

[Freexe]

The problem isn't the charset you write in. Even if you are using a iso8859-1 and type a chineese character in, your broswer will convert it to the iso-8859-1 entity code, so probably which slashdot should convert into unicode to handle and display properly

But slashcode just seems to fuck it up and display all the wrong stuff, my guess is they are displaying utf-8 but sending a iso-8859-1 header, mislabeling the content.

Re:HTML is passe

[_xeno_]

With an XBL bound element whose constructor sets document.title. :)

But seriously, I kinda hope that by the time they're complete with CSS3, you'll be able to create a stylesheet that allows you to completely define the default XHTML tag's behaviors entirely in CSS. To do this right now, you need to use non-standard stuff like XBL.

Re:HTML is passe

[Arandir]

The grandparent was claiming you could extra structure from XHTML but not from HTML, yet both have the same structure. That's my point.

This book can't be good...

[Anonymous Coward]

This book can never be any good! Everyone knows comes before !

Re:This book can't be good...

[Anonymous Coward]

This book can never be any good! Everyone knows comes before !


I don't know, I think I'd take head before html everytime...

Re:This book can't be good...

[b4k3d b34nz]

Especially on porn sites...

Head First!

[CanadianBoy]

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.

Re:Head First!

[MindStalker]

Hmm these seem to be O'Reilly books, why are they not available on safari? :(

choice between frames and CSS?

[thomthom]

I guess the choice between frames and CSS might be classified as a religious one.

eh? It's perfectly possible to use both. They don't exclude each other.

Re:choice between frames and CSS?

[The Snowman]

I guess the choice between frames and CSS might be classified as a religious one.

eh? It's perfectly possible to use both. They don't exclude each other.

When most people compare frames and CSS, they are talking about layout -- specifically, using frames to position data as opposed to CSS absolute positioning. More often, people compare CSS to table-based layout, though.

Head First doesn't cut it

[Anonymous Coward]

I bought a head first serious Java book on recommendation of one of my instructors a while ago. I ordered it online, and as soon as it arrived and I cracked the cover I regretted my decision. The style tries to be cute and 'cool', but is really very annoying and uninformative instead. I assume this trend holds true for the rest of the 'head first' series of books. Its not a series that I will be purchasing again to say the least. ;)

Re:Head First doesn't cut it

[Anonymous Coward]

A buddy of mine used Head First Java in a class last semester. When he first looked at it, he thought the same thing as you did. Then he actually read it and used it and found it was a pretty good book. I don't like the style, either, but while I can't comment on this book first-hand, I don't believe that a book written in this style is necessarily bad as a result.

Re:Head First doesn't cut it

[GoatMonkey2112]

It really depends on how much ADD you have. I thought it was a very good book for learning Java. Not much good as a reference book though. The Java certification books by the same authors are also good. Hopefully they will have the Java 1.5 version of the book out soon.

Re:Head First doesn't cut it

[CodeBuster]

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.

Re:Head First doesn't cut it

[Anonymous Coward]

I'm sure their intent was good, but it just didn't work in my experience. This book was actually the suggested book for a Java course when I bought it. Somewhere around 25% of the class (~100 students) actually got the book, and not one person has admitted that they liked it or found it useful.

Again, jutst my personal experience with the book. I'm sure the writer's intentins were wonderful, but in my opinion the end result fell flat.

Amazon has it for $23.07

[heffel]

Amazon has it cheaper than BN. ($23.07 vs $27.96)

Re:Amazon has it for $23.07

[Mantorp]

I counter with Buy.com for $20.76

Re:Amazon has it for $23.07

[mustafap]

This does seem to be rather familar, doesn't it?

    A slashdot book review

    A comment saying "Amazon has it cheaper than BN"

How much is slashdot getting paid for these 'reviews?'

I'm not playing flame bite, I'm just getting a little bored of the 'oh look what a lovely book' articles. Come on guys, if I want ads with my content I'll watch TV, or remove the 1" strip of tape at the top of my monitor :o)

Great! This is EXACTLY what I need!

[AnswerIs42]

A book that is already out of date the day it was printed.

WHY do people bother putting these out? A waste of paper AND money. Sorry, I just can;t see this being a worthwhile book to get.

You mean "laziness and ColdFusion"

[ZX-3]

non-compliant web pages that can only be produced by a combination of laziness and confusion

...here at my job it's mostly a combination of laziness and ColdFusion.

Designing With Web Standards

[Ranger]

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.

Re:Designing With Web Standards

[pileated]

These are both very good books but they address two different audiences. Zeldman's book, which I've just finished reading for second time, is for more advanced html authors/designers. It addresses people who have been through the trials of browser incompatibilities and are looking for something better. As I said I think it's excellent. And his alistapart site shows just what great web design can be done using web standards.

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.

Don't write XHTML - stick to HTML!

[Anonymous Coward]

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. (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:Don't write XHTML - stick to HTML!

[CRCulver]

FUD. The spec for XHTML 1.0 Strict specifically allows sending content as text/html.

Hickson's article is often linked to by people who can't bother to read the XHTML specs, but most veterans recognise it as a rabid screed without an ounce of sense. Now, if he were talking about only XHTML 1.1, then he might have a point, but if he is talking about XHTML, he's clearly deranged.

Re:Don't write XHTML - stick to HTML!

[ptlis]

I can't resist the chance to pimp out the content negotiation script I wrote precisely for this purpose (conditonal serving of content to UAs that support it). It's robust, simple to use and when compared to other scripts i've looked at since writing it, follows the HTTP spec a lot more accurately* and has no 'gotchas'. Any criticism is very welcome.

*As the spec doesn't specify how to handle malformed headers i've used my own judgement as to how to deal with them.

if (HTML_can_be_found_online) {then = save_ur_$();

[Links.Mistress]

What I don't seem to understand is that any information, i.e. HTML/XHTML/DHTML/CSS can be easily found on the Web for free with a click of a button. Tutorials, guides, et cetera. I've seen the book at Borders, but just laughed. Any type of book has SOME information that can be easily accessed without spending a dime isn't worth getting. I'd rather save my two cents here. HTML is so outdated anyways.

Poorly-structured non-compliance laziness

[digitaldc]

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!?!

Re:Poorly-structured non-compliance laziness

[josepuerto]

that's defintely my style, too!

Focus

[spideyct]

I would disagree. I personally can't stand the "random, jumpy" style used by MTV in any form either. But I don't think this book is guilty of that.
They use a flashy style to draw attention to particular concepts. It is used to FOCUS.

That is very different from what I consider MTV-editing, which is used to abstract, or pile a bunch of images/concepts into a single "idea", or feeling. There is no focus.

Re:Focus

[jc42]

What I wanna see is the CSS that creates the "handwritten" notes with arrows pointing into the code.

(I'd be really impressed if they actually did that via CSS. But I'm prepared to be disappointed.)

IMHO a MUCH better CSS/XHTML book...

[goldspider]

Designing With Web Standards by Jeffrey Zeldman.

And it's cheaper .

Re:IMHO a MUCH better CSS/XHTML book...

[Doctor Faustus]

At first glance, that looks like a good choice for a book to use when you're finished with the Head First book.

Other markups

[MrNaz]

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.

Re:Other markups

[Phroggy]

HTML 4.01 Strict is just as easy to validate, just as semantic, just as strict, AND works in MSIE. Why would you recommend XHTML instead?

Re:Other markups

[juiceCake]

HTML 4.01 Strict is just as easy to validate, just as semantic, just as strict, AND works in MSIE. Why would you recommend XHTML instead?

Because we've found that declaring a strict XHTML 1.0 DTD forces Explorer to behave in regard to how it handles CSS for example.

As mentioned above, we've just nearly finished coding a site using XHTML and CSS (no tables) http://www.adrenalineonline.net and every page validates thus far with the exception of any with Amazon links (which is being looked into it.) Every page also renders well in IE 6 (and of course Firefox.)

Granted, HTML 4.01 Strict is just as semantic and most likely hasn't deprecated the start attribute as mentione above. For another site I've worked on in the past I did, indeed, use a different DTD for any pages with ordered lists that required use of the start attribute. It's just that we found the XHTML 1.0 Strict DTD helped Explorer 6 behave. That the code is already in XHTML may be beneficial in future.

There is no doubt that the web in this regard is still not rock solid and is very much transitional. I don't think we'll be getting away from the "pain" of its evolution for a while. As a result, some odd reasons arise for doing things. It's a mixed bag still, obviously.

I'm halfway through this book right now.

[newdamage]

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.

great book

[wwmedia]

i actually bought this book, its very good as a reference

i love all "Head First .." series books

Alternative to innerHTML?

[tepples]

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?

Re:Alternative to innerHTML?

[Freexe]

createNode and attachNode just like the old days :)

Check out http://script.aculo.us/ for a javascript class called Builder, works well.

innerHTML isn't deprecated, it's just that it's in a grey area. What you are doing is inserting a character data node into the DOM not element nodes. So accessing the data again shouldn't be possible (although i imagine many browsers will fudge this for you just like the good old days)

Re:Alternative to innerHTML?

[tepples]

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/ 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:Alternative to innerHTML?

[Bogtha]

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?

You can do it with DOM3LS, although I don't know if that's the easiest way. I was under the impression that the W3C were going to standardise an innerHTML/innerXML property.

Re:Alternative to innerHTML?

[Freexe]

http://wiki.script.aculo.us/scriptaculous/show/Bui lder

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:Alternative to innerHTML?

[tepples]

as you don't have to supple innerHTML a well formatted string, there are no guarantees. document.innerHTML('blah &b lalala&'); is valid javascript, but it certainly isn't valid XHTML.

Wouldn't the failure of innerHTML to parse the string into DOM nodes just cause a runtime error, or at least a null result and no modification of the DOM?

Re:Alternative to innerHTML?

[Freexe]

It would just put it into the DOM as CDATA, your browser would treat it as html and try and parse it. It's not XML though, so it's not XHTML.

I see innerHTML as lazy, it only takes a few moments to create a proper node set. String manipulation is so 1990.

Re:Alternative to innerHTML?

[Bogtha]

innerHTML just sticks some string in CDATA and plops on the DOM.

No it doesn't. If it did that, there'd be no point in using it. innerHTML takes a string and parses it into a bunch of Nodes, which is then inserted into the document.

as you don't have to supple innerHTML a well formatted string, there are no guarantees.

That doesn't mean the technique is fundamentally incompatible with XML though. If you supply a string that would result in a malformed document, the browser can throw an exception instead.

Re:Alternative to innerHTML?

[justMichael]

I see innerHTML as lazy, it only takes a few moments to create a proper node set. String manipulation is so 1990.

Unless you care about performance on the client, which depends entirely on the app you are building. Yes using the DOM is cleaner, but apparently innerHTML is faster to write and to execute. That said, I generally use the DOM.

Re:Alternative to innerHTML?

[Anonymous Coward]

something along the lines of:

var subDoc = Document.loadxml(stringDoc);
parent.appendChild(subDoc);

I'm not in the mood to look up the actual code if that's incorrect, but you just create a Document Fragment object and load the string as a doc fragment, then attach it like any other node. Frankly, there should be a method to do this correctly. Call it innerXML or something.

Re:Alternative to innerHTML?

[Freexe]

innerHTML doesn't do that, the browser does! which makes the technique incompatible with xhtml.

Reviewerwho?

[DysenteryInTheRanks]

I guess the choice between frames and CSS might be classified as a religious one.

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.

Re:Reviewerwho?

[CodeBuster]

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 can understand where you are coming from on these types of issues and you can do whatever you want with your own sites, but it would be foolish not to see the other side of that coin as well. The web was built upon standards and would not be nearly as large, widespread, or useful as it is today without these types of agreements. If the web were instead released with proprietary formats, DRM, and vendor lock in then it would never have gotten off the ground. Ultimately the standards benefit everyone and the smaller developers especially, so the next time you use a deprecated tag you can go right ahead and that is fine...nobody is going to break down your door or tell you that you cannot do that, but most people agree that the newer standards have some value. Take skiing for example, I have been skiing for ten years now on a pair of shorter modern side cut skis, but every once in a while I still see an old hold-out on his 1980s vintage Olin Mark IVs because that is the way he learned to ski and he wont switch come hell or high water, even though almost everyone concedes that shaped skis are superior, because that is the way he has always done it and it is good enough for him. I am not saying that it isn't his right to ski on whatever he wants, but at some point we have to recognize when we are just being stubborn and shooting ourselves in the foot in the process. Apologizes for the rambling tone of this post, but thanks for reading all the way through...The basic point was that we should all care about the standards because we all have a stake in the way things are going.

Re:Reviewerwho?

[Bogtha]

I use the deprecated b tag all the time

The <b> element type is not deprecated.

Re:Reviewerwho?

[Fallingcow]

I seem to remember xhtml strict compliance checkers bitching when I've accidentally used bold and italic tags in the past (old habits die hard).

This page says that bold and italic are merely discouraged, but that the underline tag is no longer allowed.

Re:Reviewerwho?

[Bogtha]

Why are you letting third parties tell you what is and isn't allowed? Just look at the specification. XHTML 1.0 refers to this specification, and XHTML 1.1 is no different.

Re:Reviewerwho?

[Aewyn]

love to use tables, because they WORK for displaying on various screen sizes,

No, they don't. That's why mobile browsers have to waste resources breaking such pages up to make them somewhat usable on small screen devices.

Heck, even in 1024x768 I'm occasionally forced to maximize the browser window (or use Opera's Fit-to-width function), to avoid constantly having to scroll horizontally.

Re:Reviewerwho?

[VGPowerlord]

However, it should be noted that the current XHTML 2 Working Draft doesn't have b or i tags in it, dropping them in favor of stylesheets or strong & em.

Re:Reviewerwho?

[Phroggy]

If you write valid HTML 4.01 Transitional, you can keep most of your old familiar tags, keep your nested tables, use CSS when you want, AND get all the advantages of writing valid code: it works more consistently across browsers, and HTML validation tools (including http://validator.w3.org/) can save you hours of time tracking down weird rendering bugs caused by stupid typos.

The basic hoops you have to jump through:

1. Add a DOCTYPE declaration at the top
   
2. Specify the character set with the Content-type header (you can use a meta tag)
   
3. Add alternate text for blind users to every image (for unimportant decorative images alt="" is fine)
   

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:Reviewerwho?

[juiceCake]

Love to use tables, because they WORK for displaying on various screen sizes...

So does CSS. Fabulous for scaling to various screen sizes. There are advantages and disadvantages to both and how we weigh them will differ.

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.

You'd probably care if your clients wanted pages that printed well, adhere to accessability standards, and displayed well in mobile devices.

Hotjava?

[tepples]

Of course, without Internet Explorer support, this is basically useless

Until somebody manages to write a decent CSS parser as an applet. Or is it harder to get people to install Java runtime software than to get them to install Firefox or Opera web browser?

Not that great of a book for reference or learning

[Webapprentice]

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.

IE is your roadblock

[tepples]

Well, help users to understand, and teach them to use it correctly.

"Correctly" in this case meaning on private intranets and specifically not on the public World Wide Web, as all publicly available versions of the web browser with 85 percent market share do not read XHTML anywhere close to correctly. Microsoft Internet Explorer 6 doesn't display pages sent as application/xhtml+xml at all, and sending XML as text/html is considered harmful.

Re:IE is your roadblock

[MrNaz]

I've read that document, many years ago when it was published. A millennia ago in web time. I also get referred to it regularly, as though it's some kind of brand new idea instead of the tired old elitist piece of trash that it is.

"Correctly" does not mean "only to a few private users". It means "correctly". One can send XHTML as text/html to IE and correctly to other browsers. Even that hopelessly outdated document you referred to says that IE's ability to read tag soup applied to a semantically and syntactically correct XHTML document will result in a perfectly acceptible rendering. I refer you to Appendix B in said document.

All the given reasons for not using XHTML are due to the chance of inadvertently breaking something with invalid code. So what you're really saying is:

Don't use XHTML coz you're not smart enough.

Sorry, I don't swallow this. If people are taught how and guided away from the carelessness with which web development is currently approached, XHTML can become what it was supposed to become: a stepping stone to more functional and powerful XML based markups.

Re:IE is your roadblock

[CRCulver]

"Correctly" in this case meaning on private intranets and specifically not on the public World Wide Web, as all publicly available versions of the web browser with 85 percent market share do not read XHTML anywhere close to correctly. Microsoft Internet Explorer 6 doesn't display pages sent as application/xhtml+xml at all, and sending XML as text/html is considered harmful.

This FUD gets dragged up everytime there is a story on web standards. Look at the spec for XHTML 1.0 Strict. It specifically allows text/html.

Re:IE is your roadblock

[tepples]

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.

Mistaken deprecation of li value

[tepples]

I always had the occasional deprecated HTML tag in there because it was what I was used to.

Especially because the value attribute of the li element was mistakenly deprecated in HTML 4.01 Transitional and XHTML 1.0 Transitional and mistakenly removed from HTML 4.01 Strict, XHTML 1.0 Strict, and XHTML 1.1. If the first element of the list should be numbered 13, as is the case for a track listing of Follow the Leader by Korn, then <li value="13"> is content, not presentation.

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.

I'd like to see it explained clearly to Microsoft. Microsoft Internet Explorer version 6 didn't even follow standards that were two years old at the time it was released alongside Windows XP. Don't claim that IE 7 will fix everything because the final version of IE that will ever be made available to users of Windows 98SE, Windows 2000, and Windows Millennium Edition is IE 6.

It's a JOKE, you silly people!

[Saeed al-Sahaf]

Geeeeze! Quit waving your arms around and spitting!

Which came 1st, the chicken or the Egg?

[v3xt0r]

In the case, Web Programming 'Standards' or 'Interpriters'?

Until the Interpriters that are built in to web browsers can interprit compliant 'standards-based' code correctly, then there really is no need to try to be 100% compliant w/ the W3C.

In the war of TABLES vs. DIV+CSS, I have to say that TABLES win.

I do agree that DIV+CSS is nicer, cleaner, and easier to code... but, that means nothing to me if my site that generates 1,000,000 hits/day, is not compliant w/ the browsers that the audience is using.

Say 2% of those 1,000,000 users use a browser that does not properly render DIV+CSS *ie 4/5 etc*, then you have just made a bad impression on 20,000 users, who most likely won't return to your web site.

If you could care less about those 20,000 users, then fine, but if you depend on their hits to pay your bills, then you'll understand what I'm saying.

Save some money!

[Anonymous Coward]

Save yourself some money by buying the book here: Head First HTML with CSS & XHTML. And if you use the "secret" A9.com discount, you can save an extra 1.57%!

Yup.

[ScentCone]

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.

Re:Yup.

[VGPowerlord]

I agree. They can take my &ltB> tag when they pry it from my cold, dead text editor.

Why not use <strong> instead? <strong> and <em> are structural tags that perform similarly to the <b> and <i> style tags.

Re:Yup.

[ScentCone]

Why not use <strong> instead? <strong> and <em> are structural tags that perform similarly to the <b> and <i> style tags.

Laziness (the efficient kind), combined with ejoying the elegence of shorter strings, fewer keystrokes, and easier-to-human-parse code. I know, storage and bandwidth mean, at this point, that a large document peppered with hundreds (or thousands) of more characters in tags that basicially do the same thing as a "b" isn't as painful as it used to be, but I'm a throwback. I like small source code. Yes, I'll have to give in eventually.

too much typing

[idlake]

XHTML and CSS simply aren't very good for entering manually; only total gearheads would think that XHTML is an improvement over HTML (it's an improvement only in that it is better defined).

So, just use one of the many tools like Textile, or use a WYSIWYG editor.

Re:too much typing

[segfault_0]

If you think CSS is more typing than plain HTML formatting and attributes, you obviously havent done much CSS. It can save you tons of repetive code by allowing you to define classes and formatting globally for whole groups of elements in your pages. XHTML doesnt add much code and allows you much more functionality such as searching your tags and translating pages from your site into other formats using XLST or some other transform (i.e. deliver your web pages in PDF format on the fly). Also, you would have to have limited knowledge of HTML in the first place to think that it was complete.

Re:too much typing

[MooUK]

I personally disagree. With non-self-ending tags (p, etc), it is a huge amount easier to keep track of where something ends if you HAVE to close every tag. And it's easier to visually keep track of what needs closing and what does not when that which does not is self-closed (eg. />)

I also find it much easier to keep track of what I've done with id'd tags and CSS than by embedding styles in HTML (or in style="" attributes).

I'm not saying everybody does, mind.

Re:too much typing

[idlake]

I personally disagree. With non-self-ending tags (p, etc), it is a huge amount easier to keep track of where something ends if you HAVE to close every tag. And it's easier to visually keep track of what needs closing and what does not when that which does not is self-closed (eg.
)

The notion that paragraph, line, and page breaks need an "end" is in itself broken; very few other markup languages do it that way because it is unintuitive. It shoehorning the user into a convenient representation for the computer.

I also find it much easier to keep track of what I've done with id'd tags and CSS than by embedding styles in HTML (or in style="" attributes).

Yes, on balance, having CSS is better than not having it. But CSS itself is a poor implementation of that kind of functionality.

(X)HTML and CSS are just awful designs, and XHTML fails to fix what's wrong with HTML--it merely introduces even more obscure computer science concepts into what ought to be an easy to use markup language.

Re:too much typing

[idlake]

If you think CSS is more typing than plain HTML formatting and attributes, you obviously havent done much CSS

If you think that that's what I said, you have problems with English reading comprehension.

XHTML doesnt add much code and allows you much more functionality such as searching your tags and translating pages from your site into other formats using XLST or some other transform

The issue isn't all the nifty new features XHTML has added (which may or may not be a good idea), the issue is that XHTML is an even worse markup language than HTML was.

And I think you yourself illustrate why: you have no taste and you do not think about usability, and there are so many people like you around in this industry that we are saddled with disasters like HTML, CSS, and JavaScript as "industry standards".

Re:too much typing

[segfault_0]

XHTML and CSS simply aren't very good for entering manually

If that statement and 'use a wysiwig editor' doesnt translate in some form to imply that they are too much to type then id like to hear what you really were trying to say. I think entering them manually is perfectly efficient if you know what your doing and in some caes is actually required if you want to be truly creative as far as design is concerned.

The issue is that XHTML is an even worse markup language than HTML was..

Why not give one supporting fact for this nonsensical statement? Please. Id love to hear you define a 'good' markup language in the first place. Perhaps you and others dont like some of the syntantical elements in the XHTML schema (again, id love to hear which ones if you have specifics) but i think a well formed HTML that doesnt make every web developer completely relearn every element was a perfectly intelligent next step and if you have better ideas im sure everyone would love to hear them.

And I think you yourself illustrate why: you have no taste and you do not think about usability, and there are so many people like you around in this industry that we are saddled with disasters like HTML, CSS, and JavaScript as "industry standards".

Heres a thought on usability, go get an old browser that only supports HTML (no XHTML, CSS or JavaScript) and come back and give me a report on usability. By the way, usability is a term relating to viewing a page, not coding it, and that statement really had nothing to do with the topic. If being used for years by millions and millions of people with the effect of developing the underlying techonologies to unprecedented levels and establishing new forms of commmunication for people around the world is rated a disaster, so be it.

These people didnt have hindsight and blogs on why XHTML and CSS sucks to develop their ideas from - they did it the hard way, they broke new ground. Were they perfect? Obviously not, thats why there are versions to HTML, CSS and JavaScript - to improve them. Did it make sense just to throw them out when people had so much invested in them both in web pages and in developing the technology itself? The fact is that there is more to inventing something than you let on, there is more to being backwards compatible than advertising and if you had any development background you would have some insight into these issues. Save your insults for someone who doesnt know your clueless.

We all enjoy watching you argue just to argue, but really, toss a couple of facts in there somewhere - just to keep 'em guessing. You know shock our systems. Hint: A is worse than B isnt an argument.

Re:too much typing

[idlake]

We all enjoy watching you argue just to argue, but really, toss a couple of facts in there somewhere - just to keep 'em guessing.

The facts in this case are that people are having a lot of problems writing good HTML; hence the book review, hence the reviewer's comments. But if you seriously think all is fine and dandy in HTML markup land, run some HTML validators over some real web sites some time.

By the way, usability is a term relating to viewing a page, not coding it, and that statement really had nothing to do with the topic.

That's where you're wrong. There are two kinds of usability related to HTML: usability from the point of view of the end user (of web pages produced in HTML), and usability from the point of view of the content creator. The latter matters a great deal, because if it's difficult for content creators to produce correct markup, there will be less correct markup on the web and the web will be less useful for people.

Id love to hear you define a 'good' markup language in the first place.

A good markup language is one that satisfies its requirements (i.e., it needs to be capable of delivering the content in the required form) and works well for its users (i.e., authors), according to formal usability tests and real-world metrics. As far as I can tell, the designers of (X)HTML haven't done any usability work (just like you, they probably haven't even thought about it), and the problems people are having with producing correct and portable (X)HTML in practice suggests that there are indeed design problems with it.

These people didnt have hindsight and blogs on why XHTML and CSS sucks to develop their ideas from - they did it the hard way, they broke new ground.

A, yes, throngs of 20-somethings busily reinventing the wheel "the hard way", in complete ignorance of the previous half century of computer science. You aren't seriously asserting that there has been a lot of innovation in software over the last decade, are you?

Re:too much typing

[tepples]

XHTML doesnt add much code

Yes it does. You have to send a copy of the Firefox or Opera web browser to each user agent that reports itself as MSIE. Otherwise, you have to fall back on the browser's HTML error recovery, and by then you might as well use HTML 4.

Re:too much typing

[tepples]

XHTML and CSS simply aren't very good for entering manually

That's why most developers have moved beyond notepad.exe. For example, a text editor in XML mode could autocomplete into the end tag for the corresponding start tag.

only total gearheads would think that XHTML is an improvement over HTML (it's an improvement only in that it is better defined).

And because XML is better defined than SGML, it becomes possible to embed data in other XML applications such as SVG and MathML in an XML document without having to use an XML "island" hack such as an object element with a data element.

Re:too much typing

[segfault_0]

The facts in this case are that people are having a lot of problems writing good HTML; hence the book review, hence the reviewer's comments. But if you seriously think all is fine and dandy in HTML markup land, run some HTML validators over some real web sites some time.

Well the web and this site itself shows that there are plenty that are getting by just fine. Also, my argument was for XHTML not HTML, even though for its time HTML served its purpose well. I know plenty of people who have trouble writing good C, C++, Java, and i dont take that as my que to look down my nose at those languages.

The latter matters a great deal, because if it's difficult for content creators to produce correct markup, there will be less correct markup on the web and the web will be less useful for people.

In this case i would figure that you would support XHTML due to its extensibility and its ability to be validated at edit time easily (features your blowing off in earlier posts) - and here you seem to confirm you agree. Still you argue this is a negative move. Seems your arguing both sides of the point and Im still not clear what exactly you think XHTML doesnt do properly.

..according to formal usability tests and real-world metrics.

Although people do put thought into ease of use in their languages; functionality, portability and performance are the factors that really make a language gain ground - and the programmers make that choice, not the language authors. How do you expect people to innovate in language design if you expect them to meet some artificial requirements for usability. In my experience there are many non-intuitive paradigms in modern programming languages that represent more efficient ways to manipulate information and improve the state of the art. Look at college programming courses like data structures, are you saying that lists, trees and graphs are usable? I looked around for some of these metrics, but i cant find one web site that names any of them...strange.

A, yes, throngs of 20-somethings busily reinventing the wheel "the hard way", in complete ignorance of the previous half century of computer science. You aren't seriously asserting that there has been a lot of innovation in software over the last decade, are you?

Every application on your computer. Even if they werent invented in the past 10 years, like MP3s, instant messenging and P2P apps, you wouldnt trade them for their 1995 counterparts. Obviously plenty of innovation going on. Why not take the software less than ten years old off your computer and find out, put the 95 versions back on - im sure youll find it a robust usable experience. Plus computer scientists use math, communications and electronics theory, etc. - so i guess computer science at heart is just 'reinventing the wheel' by your standards.

Re:too much typing

[segfault_0]

Which browsers support what is a whole other conversation. Ill reclarify, XHTML doesnt add much code to browsers that support it and HTML.

Re:too much typing

[tepples]

XHTML doesnt add much code to browsers that support it and HTML.

The question is not how much code an XML parser takes but who has the right under law to add the code and whether such person is willing to add the code at a price that the browser's users can afford. Too many people are going to stick with IE 6 because they bought their computers before Windows XP, the minimum requirement for IE 6's successor, was first published, and they don't want to pay at least $100 + extra RAM for the Windows XP upgrade just to get IE 7.

Re:too much typing

[segfault_0]

Well i feel sorry for them, im still gonna upgrade my software etc. I think if your using IE6, even pre-XP, your nuts.

Re:too much typing

[tepples]

I think if your using IE6, even pre-XP, your nuts.

I'll assume that by "your" you mean "you're". Problem is that 80 percent of YOUR CUSTOMERS are nuts.

Re:too much typing

[idlake]

Well the web and this site itself shows that there are plenty that are getting by just fine.

No, the web and this site shows that people are not getting by fine. HTML fails to achieve its stated design goals: almost nobody produces correct semantic markup, and even as far as physical markup goes, there are an enormous number of problems in areas such as rendering on small or large screens.

In this case i would figure that you would support XHTML due to its extensibility and its ability to be validated at edit time easily (features your blowing off in earlier posts)

Any formal language can be "validated at edit time", including HTML and SGML. As for extensibility, it often harms usability.

Although people do put thought into ease of use in their languages; functionality, portability and performance are the factors that really make a language gain ground

Indeed. And that's why the world is full of languages with lots of features and poor usability. Like (X)HTML. My point exactly.

"You aren't seriously asserting that there has been a lot of innovation in software over the last decade, are you?"

Every application on your computer. Even if they werent invented in the past 10 years, like MP3s, instant messenging and P2P apps, you wouldnt trade them for their 1995 counterparts. Obviously plenty of innovation going on.

Some time in the 1980's, computer science and industry entered the dark ages; instead of building on an enormous amount of innovation in the 1970's and 1980's, they adopted C, C++, UNIX/Linux, and VMS/NT. You can bet that I would prefer an updated version of the 1980's apps to the dregs that are currently being distributed. The reason why I don't use the old technologies has nothing to do with innovation, it has to do with interoperability: the languages and libraries of the 1980's simply don't have the tools to interoperate with the hare-brained standards that industry has settled on and in my work, that matters. Some other people around my age still use the old environments because they can and because nothing better has come along since.

MP3 is just one of many reasonable audio coding methods; what really made MP3 and other digital media happening is the increase in Internet bandwidth (when I started using it, it was 64kbits/sec between nodes, and even then, we were already thinking of, and playing around with, VoIP and video).

As for IM and P2P, they are the antithesis of innovation: instead of using the Internet the way it was supposed do (like early messaging and file sharing software did), IM and P2P add a host of features whose primary function is to tie the user to some kind of proprietary service. That's neither progress nor innovation.

Re:too much typing

[segfault_0]

Indeed. And that's why the world is full of languages with lots of features and poor usability. Like (X)HTML. My point exactly.

This excuse is something that i expect to hear from someone with a tenuous grasp on programming who thinks the industry owes it to them to make things so simple that even they can do it. Efficiency and innovation are not rationally obvious and they never will be, otherwise everyone would invent something great; a language designed under your precepts would just suck and if i wasnt so lazy i bet i could go find a handful of failed examples as well. Oh, and im still looking for you real-world usability metrics for programming languages - ill go ahead and call 'bullshit' now.

Any formal language can be "validated at edit time", including HTML and SGML. As for extensibility, it often harms usability.

Not just validated, but easily. If it was so easy to validate HTML, the syntax was complete and browers were so compliant than why would we be wanting to replace it? I see you think extensibility in programming languages is bad too; that may be the dumbest thing anyone has ever said to me on here and makes me wonder if you have ever programmed before at all - its the basis of a successful programming language, first and foremost. Also, you still havent named anything specifically wrong with XHTML and i think at this point you just dont know what your talking about.

C, C++, UNIX/Linux, VMS/NT --- all brilliant pieces of software responsible for nothing short of changing the world. Your clueless if you think that any of these were a bad move or a failure. Building on that software was entering the dark ages? They used it because there was nothing else that worked as well. Go ahead and explain where they should have gone instead when you get the chance.

IM and P2P are good innovations period, the fact that you cant see the technology despite the greedy companies shows a lack of vision. Saying their primary function is propreitary networks is clearly misleading, there are plenty of open and free versions of both. Talking about trying to tie the user to proprietary standards, did you use any of that 70s an 80s software? That was their primary goal and nothing cross-company really interoperated very well and the software had a gigantic price tag - id say new stuff is big inprovement over that crap.

Re:too much typing

[segfault_0]

Good point, doesn't mean I don't think 80% of people aren't nuts.

(I'll assume that by "mean" you meant "meant". You're comment was about a statement made in the past while "mean" relates to something occuring presently. Also, the proper usage would have been "The problem is..", otherwise your redefining the word problem. Heh, jerk.)

Re:too much typing

[idlake]

This excuse is something that i expect to hear from someone with a tenuous grasp on programming who thinks the industry owes it to them to make things so simple that even they can do it.

Whether I can hack all the messy, complicated standards the industry has settled on doesn't matter--what matters is that is hard and costly to hire people who can. But, of course, you probably like that.

I see you think extensibility in programming languages is bad too;

Extensibility often is bad, yes. Furt ragles frimands in English(*).

IM and P2P are good innovations period, the fact that you cant see the technology despite the greedy companies shows a lack of vision.

The fact that you think that IM and P2P are innovations shows a lack of historical awareness.

C, C++, UNIX/Linux, VMS/NT --- all brilliant pieces of software responsible for nothing short of changing the world.

Stalin was also brilliant and changed the world.

Your clueless if you think that any of these were a bad move or a failure. Building on that software was entering the dark ages?

Yes, as in buffer overruns, MS Office crashes and data corruption, software projects that are years late, and operating systems that have 512M as a minimum requirement and run like molasses on 1GHz machines. You know, that kind of bad.

Go ahead and explain where they should have gone instead when you get the chance.

Where the industry is going today with Java and C#: object-oriented languages with garbage collection, dynamic typing, reflection, sound error checking, and killer IDEs. All of that existed in the early 1980's, even commercially.

(*) furt := new vocabulary, ragles := negatively affects, frimands := understanding

Re:too much typing

[segfault_0]

Nonsense.

noncompliance

[Anonymous Coward]

One thing I think advocates for standards compliance and valid markup overlook is that often, websites are created on a deadline. At my job I frequently have to churn out something in a couple hours or less, and at times like those, my priorities go something like this: does it look good in IE 6? Firefox 1? Safari? Well then, OK.

Re:Not that great of a book for reference or learn

[HisMother]

Took the words right out of my mouth. The Zeldman book is a weird read. He makes you say "OK, that sounds great! Can't wait till he fills in some details ...." and then, all of a sudden, you get to the last page, and realize you didn't learn a damn thing. Grrrr.

Re:Not that great of a book for reference or learn

[Suppafly]

Zeldman and the ALA people seem to spend a lot of time making workarounds for specific versions of IE, thereby elimating the main benefit of CSS.

Re:Not that great of a book for reference or learn

[goldspider]

Those workarounds are meant for situations when you must compromise strict compliance for the sake of wider browser compatibility.

Re:if (HTML_can_be_found_online) {then = save_ur_$

[CodeBuster]

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?

out dated

[sanguisdev]

you know what would be great. if a book review was on a book that coverd current standards, not a book that covered standards form 3 years ago. we are now looking ate XHTML 2.0 and CSS 3. media types are the shit! Sanguis

Re:out dated

[Phroggy]

you know what would be great. if a book review was on a book that coverd current standards, not a book that covered standards form 3 years ago. we are now looking ate XHTML 2.0 and CSS 3. media types are the shit! Sanguis

Who's "we"? I'm looking at at least 80% of browsers that don't know what XHTML is. CSS 3? Yeah right.

Re:Not that great of a book for reference or learn

[bobdinkel]

Zeldman and the ALA people seem to spend a lot of time making workarounds for specific versions of IE, thereby elimating the main benefit of CSS.

That is frequently the case. A lot of people lose sight of the purpose of standards--to make things easier. And with that in mind, "Designing with Web Standards" is a great book if you can tune out the standards for standards' sake zealotry. For practical standards compliance I really recommend "Web Standards Solutions" by Dan Cederholm.

Re:Not that great of a book for reference or learn

[goldspider]

The Zeldman book is hardly "standards for standards' sake" zealotry. In fact there are many work-arounds in the book that compromise strict adherence to standards for the sake of borwser compatability.

The b-is-deprecated myth

[bw-sf]

is not deprecated. Everyone thinks it is for some reason.
http://www.w3.org/TR/xhtml-modularization/abstract _modules.html#s_presentationmodule

Head First Style

[Penguinoflight]

I got the Head First Java book, which was written in a similar, mind-numbing manner. It really isn't helpful, but its good for a laugh. Amazon tends to rate these books very highly, but I'd reccomend one that takes a more seriuos look; you dont need a book full of dumb analogies to understand html/css.

Re:Not that great of a book for reference or learn

[bobdinkel]

You're right, and I can admit it. It's been a while since I read the Zeldman book. I mentally grouped his book with what I used to see on ALA. And that was folks jumping through hoops to follow the web standards to no real benefit other than standards compliance. This wasn't, of course, the case every time, but it happened plenty. And at the time I was totally on board. Is it OK to use a <dl> to mark up a form? Does a form really count as tabular data? Do the benefits of FIR (standards compliance!) outweigh accessibily concerns?

That sort of thing is somewhat ridiculous. I'm feeling much better now. And I stand corrected.

b not deprecated

[bw-sf]

there's nothing in the XHTML 1.1 spec about b being deprecated ...

CSS has to improve

[jb_nizet]

XHTML and CSS are the way to go, but CSS definitely has to improve. Designing a liquid two-column with header and footer layout using CSS is a nightmare, especially if you have to support several browsers. Doing the same thing with a simple table is much more simple.
Just having the footer at the bottom of the page, and not just behind the body is (AFAIK) impossible with CSS.
The easiest solution is often to go with fixed size and absolutely positioned divs, but then you reduce the accessibility of the page (if you change the font size, the div doesn't become larger). Once again, these problems don't exist with table layouts.
IMHO, CSS has failed in the areas of layout, size and positioning.

Re:CSS has to improve

[Bogtha]

Designing a liquid two-column with header and footer layout using CSS is a nightmare

Actually, it's really simple. But Internet Explorer doesn't support that bit of CSS. So really, it's Internet Explorer that has to improve, not CSS.

Just having the footer at the bottom of the page, and not just behind the body is (AFAIK) impossible with CSS.

Not true. Here's one technique.

Re:CSS has to improve

[jb_nizet]

Actually, it's really simple. But Internet Explorer doesn't support that bit of CSS. So really, it's Internet Explorer that has to improve, not CSS.

It's simple... until you have to make it look good. Add a border between the left bar and the body that goes down to the footer, and it becomes trickier. Then add to the mix that you don't want the body to fall below the left bar when it becomes larger than expected (big images or large tables), and it's even harder. Not to mention the problems when you start additioning percents together to make it 100% and you see scrollbars appearing. No, really, CSS should have made it as easy as using tables for layout, and it hasn't.

I agree with you regarding the bad support for CSS in IE. But it's still the most used browser, and when you have to deliver real applications, CSS and IE can make you mad!

Regarding the technique mentioned for the footer, I'll bookmark it. But it validates my remarks: this technique is not well-known; it's completely counter-intuitive; it needs hacks to work in several browsers; and it needs absolute sizing of the margin of the footer, which make it less accessible. Things should be easier than that.

Hixie and XHTML Appendix C

[tepples]

I also get referred to it regularly, as though it's some kind of brand new idea instead of the tired old elitist piece of trash that it is.

Is a well-written rebuttal to hixie's screed available on the web?

One can send XHTML as text/html to IE and correctly to other browsers.

But then you have to sniff the Accept: header and generate either XHTML or HTML 4. This rules out users in environments that do not provide for dynamic content, such as ISP web space, university web space, and banner-supported free web space.

The thing very few XHTML advocates remember is that the interpretation of the / character differs incompatibly between conforming implementations of XML and SGML. For instance, under the (sometimes obscure) SGML SHORTTAG rules used by HTML 4, / is a shortcut for starting and ending an element body, meaning that <em/emphasized/ in HTML 4 is equivalent to <em>emphasized</em>. In XML, on the other hand, / always denotes an empty element such as <br />, but in SGML, that means the same thing as <br>>. But you're right that most existing HTML user agents support the <dl compact> part of SHORTTAG but not the <em>emphasized</em> part of SHORTTAG, which is the deficiency that makes the Appendix C hack work in practice.

Still, what about the CDATA/PCDATA differences that require inline script and CSS to be escaped using ridiculously complex ASCII art gymnastics? What about the mistaken removal in XHTML 1.1 of the value attribute of the li element, making it impossible to start an ol element at any value other than 1? And what about the differences in CSS semantics, DOM semantics, and the fact that W3C deprecated the practice?

XHTML can become what it was supposed to become: a stepping stone to more functional and powerful XML based markups.

But first we need a stepping stone to the stepping stone, in the form of a widely deployed web browser that understands the CSS and DOM semantics that go with XHTML. Then once XHTML 1.0 is adopted, how long will it be before we can move on to XHTML 1.1, which drops Appendix C and the transitional dialect entirely, or XHTML 2.0, which even renames many of the existing elements?

Re:Hixie and XHTML Appendix C

[Bogtha]

Is a well-written rebuttal to hixie's screed available on the web?

Not that I'm aware of, and I don't expect one to arise. The problem is that his argument is basically "Serving XHTML as text/html is harmful because people do it incorrectly!", to which the only really sensible reply is "Well don't do it incorrectly then!" The harm comes from doing it incorrectly, not the fact that you are doing it at all. Nobody's going to write a rebuttal, because that would entail arguing that doing it incorrectly was right, and nobody thinks that.

But then you have to sniff the Accept: header and generate either XHTML or HTML 4. This rules out users in environments that do not provide for dynamic content

I agree that content negotiation for this purpose isn't very useful, but 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 what about the differences in CSS semantics, DOM semantics, and the fact that W3C deprecated the practice?

You are misreading that last link. It's talking about whether or not it's appropriate for a user-agent to treat XHTML sent as text/html as if it is "real" XHTML and not just tag soup. The W3C haven't deprecated sending XHTML 1.0 as text/html, and even if they wanted to, they cannot - it's the IETF who decide what can be labelled as text/html, as they are the ones who publish the RFCs governing MIME media types.

Re:Hixie and XHTML Appendix C

[tepples]

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?

Amen to that

[macguiguru]

Designing With Web Standards is a superb book that explains the WHY, then the HOW quite clearly. I strongly recommend it.

Save $4.95 by buying the book here!

[Anonymous Coward]

Save yourself $4.95 by buying the book here: Head First HTML with CSS &amp; XHTML. And if you use the "secret" A9.com Instant Reward discount, you can save an extra 1.57%! That's a total savings of $5.31, or 19.27%!

This book is not up to the standard of the series

[RealBeanDip]

Hate to rain on the parade here, but I have both Head First Java (EXCELLENT) and Head First Design Patterns (also EXCELLENT) and this book.

IMO, this book is not even close to the other two. The other two have a nice flow, while this book feels jumpy and cobled together. It's like the other with the fun sidebars and graphics, but just not as well done. I'd like to offer some specifics but the book is on the shelf in my office and I'm home - I just know I wasn't impressed with it like the other two. I literally read the other two cover to cover, this one was worth a couple of chapters at best.

Re:if (HTML_can_be_found_online) {then = save_ur_$

[Links.Mistress]

"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..." Try Fravia searchlores: http://www.searchlores.org/ "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's not to say someone can't test it out. I mean, HTML and CSS is used even in MYSPACE, where you can correct/check/and teach/experiment with the information you're given. You're thinking a bit too much like my teachers; not all information is wrong, and there's more than hundreds of ways to find it. I learned CSS and HTML on my own, not by tutorials, but by fooling around and testing things out and observing the code. Don't forget; is money the issue here? We can both agree on the same thing. Someone can just sit down and READ the book IN the store (without spending $$), or actually take it out. I've seen people (like me) in the tech/sci section of borders jotting things down. If money is the issue; I say dont get it. If it's for the actual KNOWLEDGE you get from reading the book, I encourage information. Books are just as good as computers. But money's what the main article's all about. "....that and the main point which was how much is your time worth?" It's up to the buyers of what they want to do. They can either spend $30 on a book, search google, or copy + paste random code on Myspace. It's up to the readers to decide who they are and what they're gonna do. Niether one takes more/less time than the other. And if they haven't got the time, what are they doing? Writing scripts doesn't happen in a night! But you have a good argument :)

Not a chance.

[conJunk]

Really... a few nested tables work just FINE.

No. They don't. For you all who don't understand the point of standards and tableless design, let me break it down:

The whole point of design that involves compliant markup and avoids the use of tables is this: it is 100% portable to any device, and to any user. Your PDA or mobile phone (as well as your blind friend's screen reader and your deaf-blind-friend's braille display) need to receive document structure and text only. Then they can present as best fits that device. When you wack a bunch of stuff into tables, you are essentially requiring your user to have a visual display. It's not portable, and it's not accessible. It totally blocks all kinds of groupos: mobile phone users, pda users, users with disabilities, etc. out of your content. To a lesser extent, it hinders search engine spiders and is bad for SEO.

Totally separating content&structure from presentation is the only way to make sure that your document is portable across platforms.

FUD! - open _this_ page in IE

[newr00tic]

IE can do more than just fonts (I'm not saying this to support IE; Personally, I think it sucks,) check the page beneath my nick. -There _could_ be xhtml errors there, (I doubt it,) but IE renders it just fine, or; just like Firefox..

And yeah; I haven't tested it in IE7, as that browser is not complete yet.

(Never-mind the content, and, yes; the page is simple..)

Re:FUD! - open _this_ page in IE

[MikeFM]

It looks nice but it still is avoiding some of the more interesting position options it seems. It's the little details that make it hard to implement some layouts for IE.

Re:FUD! - open _this_ page in IE

[Anonymous Coward]

Actualy tidy gives some warnings....

Re:if (HTML_can_be_found_online) {then = save_ur_$

[reallocate]

The book is about XHTML and CSS, but since you apparently don't read many books, you wouldn't know that.

I thought the book was one of the most successful teaching tools I've read in years. There's a world of difference between Googling for bits of reference material, and reading a 400-page narrative built by people who know how to teach.

Reading reference material is not learning.

Link?

[Anonymous Coward]

I'd like to see what you put up for IE users....

Re:Link?

[Tom]

You can follow the link in my .sig, sign up for the game and look at the dynamic map in the info menu. But here's the text:

You seem to be using IE as a web browser. The dynamic map will not work
with IE, including the AOL version. This is due to IE being buggy.
The dynamic map is proper CSS 2.0 and even verifies without warnings
as HTML 4.01.

We suggest that you upgrade your browser to something like
Mozilla or Opera
or any other modern, standards-complient browser. We recommend Firefox, the
most recent Mozilla browser:

Get Firefox

If you are, in fact, using one such and have just configured it to identify
itself as MSIE, or if you insist to see how IE mangles proper Internet
files, go ahead, but don't complain.

Re:if (HTML_can_be_found_online) {then = save_ur_$

[Q2Serpent]

On the opposite side of the argument, if I had purchased a book for each topic that I have learned over the 5 years I have spent developing code and reading online resources, I would have spent a ridiculous amount of money by now.

sorry

[newr00tic]

Yeah, in hindsight I saw what you really meant; my apologies. It just initially seemed like a dash to "deny" IE of the things it _can_ do, and I was a bit quick on the 'ol triggy there.. all pardons

Re:sorry

[MikeFM]

I find that IE makes it hard to implement non-squarish designs where elements overlap a lot.

A story has a beginning and an end

[tepples]

The notion that paragraph, line, and page breaks need an "end" is in itself broken

A page has a start (top of page) and an end (bottom of page). A paragraph has a start (visually rendered as indent or double space) and an end (often rendered as a line without full justification). A list item has a start (start of line) and an end (end of line). A line of poetry also has a start and an end. If you stop thinking of tags as having meanings in and of themselves and start thinking of them as wrappers around elements of an object, it becomes clearer.

Save $1.39 by buying the book here!

[Anonymous Coward]

Save yourself $1.39 by buying the book here: Head First HTML with CSS &amp; XHTML. And if you use the "secret" A9.com Instant Reward discount, you can save an extra 1.57%! That's a total savings of $1.75, or 7.25%!