×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Head First HTML with CSS & XHTML

samzenpus posted more than 8 years ago | from the jump-in dept.

Book Reviews 197

Graeme Williams writes "In the past, I've written the sort of poorly-structured non-compliant web pages that can only be produced by a combination of laziness and confusion, so I'm an ideal test subject for Head First HTML with CSS & XHTML, an introduction to building web pages which focuses on compliance with the most recent HTML 4.01 standard and XHTML 1.0 standard. The book starts with the simplest of web pages, and builds from there to a solid foundation for writing simple well-structured web sites. It's clear and thorough, and will be effective both for the complete beginner and in bringing stale skills up to date." Read on for the rest of Graeme's review.

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.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

197 comments

First Ninnle Post (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#14636911)

Ninnle!

Wow, man!

More HTML books need to talk about CSS (5, Interesting)

VGPowerlord (621254) | more than 8 years ago | (#14636944)

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 (3, Interesting)

MikeFM (12491) | more than 8 years ago | (#14637212)

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 (1)

a803redman (870583) | more than 8 years ago | (#14637486)

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

Re:More HTML books need to talk about CSS (1)

CRCulver (715279) | more than 8 years ago | (#14637601)

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 (4, Funny)

Rayooz (22049) | more than 8 years ago | (#14637637)

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 (4, Interesting)

MikeFM (12491) | more than 8 years ago | (#14637658)

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 (1)

b4k3d b34nz (900066) | more than 8 years ago | (#14637955)

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.

The simplest standards compliant webpage EVAR (0)

Anonymous Coward | more than 8 years ago | (#14636955)

<html>
</html>

Re:The simplest standards compliant webpage EVAR (2, Funny)

terwey (917072) | more than 8 years ago | (#14636996)

*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 (1)

The Snowman (116231) | more than 8 years ago | (#14637083)

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

Re:The simplest standards compliant webpage EVAR (2, Informative)

Bogtha (906264) | more than 8 years ago | (#14637138)

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 (0, Flamebait)

Thaidog (235587) | more than 8 years ago | (#14636997)

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 (1)

Potato Battery (872080) | more than 8 years ago | (#14637068)

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 (1)

Thaidog (235587) | more than 8 years ago | (#14637423)

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 (1)

Fallingcow (213461) | more than 8 years ago | (#14637831)

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 (1)

Fallingcow (213461) | more than 8 years ago | (#14637848)

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 (1)

Bogtha (906264) | more than 8 years ago | (#14638157)

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 (1)

b3x (586838) | more than 8 years ago | (#14637073)

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 (2, Insightful)

DigitalRaptor (815681) | more than 8 years ago | (#14637182)

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 (2, Informative)

zqad (612317) | more than 8 years ago | (#14637238)

Last time i checked, IE does NOT cope correctly with for example the ACID2-test [http://webstandards.org/act/acid2/test.html#top [webstandards.org]]. 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 (1)

TubeSteak (669689) | more than 8 years ago | (#14637554)

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 (1)

Irish_Samurai (224931) | more than 8 years ago | (#14637263)

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.

Uh-oh! (3, Interesting)

Billosaur (927319) | more than 8 years ago | (#14636999)

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! (4, Insightful)

kelzer (83087) | more than 8 years ago | (#14637078)

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! (5, Interesting)

Excelsior (164338) | more than 8 years ago | (#14638111)

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! (1)

twbecker (315312) | more than 8 years ago | (#14637145)

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.

Focus (1)

spideyct (250045) | more than 8 years ago | (#14637158)

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.

Head First Style (1)

Penguinoflight (517245) | more than 8 years ago | (#14638052)

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.

HTML is passe (1, Interesting)

ravee (201020) | more than 8 years ago | (#14637002)

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 (2, Insightful)

Arandir (19206) | more than 8 years ago | (#14637189)

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 (2, Interesting)

Freexe (717562) | more than 8 years ago | (#14637213)

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 (1)

Freexe (717562) | more than 8 years ago | (#14637226)

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

(/s/docutype/doctype)

Alternative to innerHTML? (2)

tepples (727027) | more than 8 years ago | (#14637301)

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? (1)

Freexe (717562) | more than 8 years ago | (#14637361)

createNode and attachNode just like the old days :)

Check out http://script.aculo.us/ [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? (2, Informative)

tepples (727027) | more than 8 years ago | (#14637548)

createNode and attachNode just like the old days :)

So what's the accepted DOM function that, given a string of markup, parses the markup to give me one or more nodes that I can attach?

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

The page you linked does not contain the word "Builder", and neither does the Prototype library linked from there. If it's part of the script.aculo.us library, I'm not in a position to evaluate that library as I write this comment. Besides, would it run nearly as fast as the browser's built-in markup parser, which I assume is used for handling the innerHTML property?

What you are doing is inserting a character data node into the DOM not element nodes.

If I were inserting character data instead of markup to be converted to element nodes, then I would use the innerText property, not the innerHTML property.

Re:Alternative to innerHTML? (1)

Bogtha (906264) | more than 8 years ago | (#14637634)

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 [w3.org], 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? (2, Informative)

Freexe (717562) | more than 8 years ago | (#14637847)

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? (1)

tepples (727027) | more than 8 years ago | (#14637953)

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? (1)

Freexe (717562) | more than 8 years ago | (#14638107)

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:HTML is passe (4, Informative)

_xeno_ (155264) | more than 8 years ago | (#14637230)

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.

Hotjava? (1)

tepples (727027) | more than 8 years ago | (#14637338)

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?

Re:HTML is passe (3, Informative)

Bogtha (906264) | more than 8 years ago | (#14637551)

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 [ietf.org], 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 (1)

_xeno_ (155264) | more than 8 years ago | (#14637702)

Perhaps according to you, but not according to RFC 2854 [ietf.org], 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 (2, Informative)

Bogtha (906264) | more than 8 years ago | (#14637954)

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 (1)

rodentia (102779) | more than 8 years ago | (#14637865)


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 (1)

kfg (145172) | more than 8 years ago | (#14637966)

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

gaspar ilom (859751) | more than 8 years ago | (#14637864)

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

This book can't be good... (4, Funny)

Anonymous Coward | more than 8 years ago | (#14637005)

This book can never be any good! Everyone knows <html> comes before <head>!

Re:This book can't be good... (1, Funny)

Anonymous Coward | more than 8 years ago | (#14637378)

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


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

Head First! (5, Insightful)

CanadianBoy (868003) | more than 8 years ago | (#14637008)

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.

choice between frames and CSS? (2, Informative)

thomthom (832970) | more than 8 years ago | (#14637046)

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? (1)

The Snowman (116231) | more than 8 years ago | (#14637095)

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 (1, Interesting)

Anonymous Coward | more than 8 years ago | (#14637050)

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 (0)

Anonymous Coward | more than 8 years ago | (#14637335)

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 (1)

GoatMonkey2112 (875417) | more than 8 years ago | (#14637555)

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 (2, Interesting)

CodeBuster (516420) | more than 8 years ago | (#14637769)

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.

Amazon has it for $23.07 (2, Informative)

heffel (83440) | more than 8 years ago | (#14637055)

Amazon [amazon.com] has it cheaper than BN. ($23.07 vs $27.96)

Re:Amazon has it for $23.07 (1)

mustafap (452510) | more than 8 years ago | (#14637252)

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! (0, Troll)

AnswerIs42 (622520) | more than 8 years ago | (#14637062)

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" (5, Funny)

ZX-3 (745525) | more than 8 years ago | (#14637075)

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.

Don't write XHTML - stick to HTML! (1, Informative)

Anonymous Coward | more than 8 years ago | (#14637107)

Or at least, don't write XHTML unless you really know what you're doing, and know to send real XHTML (application/xhtml+xml) to compliant browsers.)

Sending XHTML as text/html Considered Harmful [hixie.ch]. (Written by Ian Hickson, who's an editor of half a dozen CSS drafts, QA person for Mozilla, ex-QA for Opera, and nowadays works on 'HTML 5' (WHATWG web apps) for Google.)

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

Links.Mistress (951816) | more than 8 years ago | (#14637116)

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.

Re:if (HTML_can_be_found_online) {then = save_ur_$ (2, Insightful)

CodeBuster (516420) | more than 8 years ago | (#14637867)

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?

Poorly-structured non-compliance laziness (2, Funny)

digitaldc (879047) | more than 8 years ago | (#14637136)

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!?! [gmu.edu]

IMHO a MUCH better CSS/XHTML book... (5, Interesting)

goldspider (445116) | more than 8 years ago | (#14637183)

Designing With Web Standards [zeldman.com] by Jeffrey Zeldman [zeldman.com].

And it's cheaper [amazon.com] .

Not that great of a book for reference or learning (2, Interesting)

Webapprentice (608832) | more than 8 years ago | (#14637379)

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.

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

HisMother (413313) | more than 8 years ago | (#14637735)

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 (1)

Suppafly (179830) | more than 8 years ago | (#14637777)

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 (1)

goldspider (445116) | more than 8 years ago | (#14637804)

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

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

bobdinkel (530885) | more than 8 years ago | (#14637890)

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 (1)

goldspider (445116) | more than 8 years ago | (#14637938)

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.

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

bobdinkel (530885) | more than 8 years ago | (#14638143)

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.

Re:IMHO a MUCH better CSS/XHTML book... (1)

Doctor Faustus (127273) | more than 8 years ago | (#14637900)

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 (3, Insightful)

MrNaz (730548) | more than 8 years ago | (#14637192)

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/ [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.

IE is your roadblock (1)

tepples (727027) | more than 8 years ago | (#14637384)

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 [hixie.ch].

Re:IE is your roadblock (1)

MrNaz (730548) | more than 8 years ago | (#14637631)

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.

I'm halfway through this book right now. (3, Informative)

newdamage (753043) | more than 8 years ago | (#14637249)

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.

Mistaken deprecation of li value (1)

tepples (727027) | more than 8 years ago | (#14637443)

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.

great book (2, Interesting)

wwmedia (950346) | more than 8 years ago | (#14637271)

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

i love all "Head First .." series books

Reviewerwho? (3, Interesting)

DysenteryInTheRanks (902824) | more than 8 years ago | (#14637307)

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.

Yup. (2, Insightful)

ScentCone (795499) | more than 8 years ago | (#14637605)

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:Reviewerwho? (1)

CodeBuster (516420) | more than 8 years ago | (#14637649)

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? (1)

Bogtha (906264) | more than 8 years ago | (#14637653)

I use the deprecated b tag all the time

The <b> element type is not deprecated.

Re:Reviewerwho? (1)

Fallingcow (213461) | more than 8 years ago | (#14638002)

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 [webpageworkshop.co.uk] says that bold and italic are merely discouraged, but that the underline tag is no longer allowed.

Which came 1st, the chicken or the Egg? (1)

v3xt0r (799856) | more than 8 years ago | (#14637481)

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! (0)

Anonymous Coward | more than 8 years ago | (#14637513)

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

too much typing (1)

idlake (850372) | more than 8 years ago | (#14637613)

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.

noncompliance (0)

Anonymous Coward | more than 8 years ago | (#14637650)

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.

out dated (1)

sanguisdev (918861) | more than 8 years ago | (#14637884)

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
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...