i am dustin diaz

DOM Scripting Book Review

Over the past 6 weeks, I've had the privledge of reading some very well defined thoughts by Jeremy Keith about the notoriously misunderstood language called JavaScript. And for what it's worth, Jeremy would like to appropriately rename this scripting language to DOM Scripting which I feel dresses up JavaScript into a nice suit and tie to behave and act a bit more professional (like we should be). This entry is mainly for Jeremy's benefit, but hopefully other readers will benefit as well. It may even convince some to buy the book after glancing over just a few of my comments. First things first, I took notes while reading the book on separate pieces of paper according to page number and paragraph (if noted). With that said, I've done my best to piece together what I felt is appropriate and constructive without detering too much on how nerdy I think Jeremy is. The fact of the matter is, anyone who comes up with a make-believe band called JaySkript and the DOMsters is just asking for it. However, secretly inside I was thinking Oh sweet, how cool is that.

Overall impression

I decided to begin with this first mainly for purposes of those who like to skim and not read far ahead. That's ok, I can dig that. I've done that too... After finishing the book and laying it down, I learned these three things:

• Jeremy's love for Simon's addLoadEvent() which was printed nearly six times over in its entirety throughout the book
• The insertAfter() function. It's really a shame I haven't thought of this kind of function before. Similar to the insertBefore() function provided by the JavaScript language, insertAfter does just what you think it does.
• How much Jeremy and I really do think alike. On more than several occassions I challenged myself to come up with a function (or group of functions) based on Jeremy's description on what he wanted to do, and nearly most of them he had a near exact idea of my own concepts. Weird.

The fine details

The rest of these ramblings are taken directly from the pieces of paper noted in order by page number. page 96 ^{4th paragraph}: Jeremy said:

Is the JavaScript Unobtrusive? - Ideally, I should attach the onclick event in the external JavaScript file

An event and eventHandler are two different things. The simplest way to tell the difference is by the mere prefix of 'on'. Thus, 'onclick' is an eventHandler, not an event. Events are attached, eventHandlers are set and are more inline-esk. Yet, they both can be set unobtrusively (as you were referring to). page 97 Another occurrence of event vs eventHandlers. page 98 Jeremy illustrated a few ways to write JavaScript and it felt kind of like a "best practices" dealio on what is considered readable. Not that I disagree with his methods since I practice them myself, I just think it's mostly opinion. page 99 Jeremy lists 3 sample keywords to avoid in the JavaScript language. I felt this was sort of inadequate. Albeit this being geared more toward developers wanting to get their feet wet with language, I think it would be appropriate to at least put a link to a reference where one can view all reserved keywords. It would be a short and simple addition. page 110 Jeremy said this: Beware of onkeypress. Now, I don't remember why, but I wrote this down: You didn't even mention keycodes. Do what you will with that. I'm sure I was on to something... Chapters 4, 5, & 6: The reader goes through three long chapters before Jeremy lets them know how to create markup on the fly. I read all this without looking ahead and thought to myself We still have this random placeholder (referring to the demo gallery script), when are we going to ditch that! And it wasn't until chapter seven where you mention creating markup. Possibly something to consider telling the reader: let them know that "we'll be tackling that issue at a latter point in the book" It seems in several cases where Jeremy teaches the reader some practices, but then have them unlearn those practices in later chapters. However, I'd refrain from saying "teach", but more like "demonstrate". Note to Jeremy: I'm not sure how valid my last comment was, especially coming from someone who is yelling outloud going "What about graceful degradation - we should be creating markup on the fly??!!" One thing I always thought a good educator does is forwarns. It's almost like an "I told you so". If someone picks up your book and after the first six chapters puts down the book for good, they will have walked away thinking it's ok to keep their <div id="placeholder"></div>. Catch my drift? page 137: Is it really necessary to itterate through a line four times because it's more readable? For instance, Jeremy has this:

4x the iteration

if ( !object ) return false;

if ( !object ) return false;

if ( !object ) return false;

if ( !object ) return false;

Can easily and simply be rewritten like this:

1x the iteration

if ( !object || !object || !object || !object ) {

  return false;

}

In later chapters, I found out Jeremy does actually end up doing this. (note to self, be patient with Jeremy). page 138: This has a little to do with Jeremy's love for addLoadEvent(). Not to criticize the function or its usefulness, but I think we can do a little better on how we're setting up our 'load' events. Although addLoadEvent() is simple to include anywhere, I would think it would be more practical to avoid using it so much... perhaps setting up a general loadGroup. For example, instead of this:

multiple instances of addLoadEvent

addLoadEvent(funcA);

addLoadEvent(funcB);

addLoadEvent(funcC);

Try something like this instead:

one instance of addLoadEvent

function myLoads() {

  funcA();

  funcB();

  funcC();

}

addLoadEvent(myLoads);

So in book's example, it could be rewritten like this:

photoGallery load event

function photoGal() {

  preparePlaceHolder();

  prepareGallery();

}

addLoadEvent(photoGal);

page 146: Here I'm a bit concerned on Jeremy's interchanging of the acronym "DOM" and JavaScript. In the What not to do section on this page, Jeremy says:

If you find yourself using the DOM to add important content...

This may be due to my own lack of understanding of what the DOM really really is. I mean really. I can dig the phrase "DOM Scripting". Yea, it's catchy and kind of makes sense. It's like a new wave of scripting. Or better yet: Scripting on the DOM. But here I think what Jeremy really meant is to use JavaScript to add important content. I am very unclear how you can use the DOM to actually insert content. My understanding of the DOM is that it's this large object... of your (web) document. The DOM can be manipulated by JavaScript... and not visa-versa. On the contrary, I could be wrong, but I definitely think I'm onto something... page 147: Jeremy says:

CSS are very powerful tools

Technically, that's a very correct statement. But doesn't it just sound weird? Say the acronym to yourself within the sentence... "See Ess Ess are very powerful tools". I don't know, but I'd reword it to say something simple like "Style Sheets are very powerful tools". You could completely ignore this if it doesn't make sense. page 149: Do you really think html will be deprecated entirely? Last I heard, Hakon Lie (Inventor of C.S.S.) thinks html will be around for at least another fifty years according to his tech talk here at Yahoo!. I guess he made a bet with someone. page 160: duplicate content. Jeremy, you've already explained the addLoadEvent() (and its benefits) earlier in the book. You could just throw out a page number and leave it to readers choice is they want to remember. page 162: On Two possible Solutions to developing this script, I'm just wondering if the example is a 'real-world' example, or just used for the sake of having an example to show off some graceful degredation. Off the top of my head, I don't remember what the example was for. page 183: One thing I've noticed in general at this point is the lack of reference. I understand this wasn't going to be an oreilly bible book to list every function in JavaScript since 1994, however it's nice to know that there's more out there. On this page specifically, you mentioned the camelCase style for fontFamily, but then fail to mention anything else or at the least point to a reference online where folks can find a complete list of JavaScript style properties. page 185: Ok, since we're talkin' CSS shorthand here, I think my input is valid. For the font shorthand property, Jeremy has this example:

font shorthand property example

p { 

  font:12px 'Arial', sans-serif;

}

One this is for sure, you don't need the quotes around 'Arial' and nor does it need to be capitalized. The only uses for quotes on fonts is when the name of the font has spaces in it. The other issue is there is no mention of unexplicit values that are set such as font-variant, font-weight, font-style, and line-height. Checkout my CSS Shorthand Guide. That's be sweet if I made it in Jeremy's book ;) page 196: I've rewritten the stripeTables() to be a bit quicker. The purpose of this function was to alternate row colors of a table. Basically, instead of looping through each row one at a time and adding a className of 'alt' to every other row, I felt that it's only appropriate to 'skip' every other one by adding 2 instead of one...for example:

stripeTables function rewritten

function stripeTables() {

  ...

  for ( var j=0; j<rowLen; j=j+2; ) {

    // add className to row

  }

  ...

}

page 201: Is there really a problem with appending a ' ' (space) at the beginning of a className? Seems to work in IE6, Moz, Safari, and Opera. I must be missing something... page 209: addLoadEvent() strikes again in full effect. lol. Chapter 11: In general, what happened to DOM Scripting? You've snuck in a chapter that doesn't give Modular CSS justice. Should probably at the least consider putting references to online resources that explain this type of CSS architecture like Bowman's or Content with Style's piece on modular css. Just a thought. page 256: *cough* addLoadEvent() page 258: Jeremy asks how we could have solved the problem of getting the body to have an id while being in an include file...or something like that. In short, simply take out the body element and keep it on your separate pages. Done. page 260: Ok, this was freaky, I think I'm using the same exact function on my website without having never seen it before. It's the one used to append a "You are here" tab. I told you great minds think alike. page 299: Jeremy says:

Ajax involves the use of JavaScript, CSS, the DOM, & XML

Last I checked, Adaptive Path said it went along the lines of something like "Asynchronous JavaScript and XML"... but I hear where you're coming from Jeremy.

In Conclusion

Jeremy, if you read this entry (which I hope you have), I would encourage you to take this like any other criticism. I meant it whole heartedly and positively constructive as I possibly could. Not everything I say is correct or needs to be considered. These were just my thoughts from an experienced developers perspective. Overall I think you've done very well with the book and I recommend your book to anyone looking to get their hands dirty with the DOM for the first time. Note to everyone else: Buy this book! It's everything I would have wanted to say had I been given the privledge to write one.

Oh, and one last thing, Jeremy, looking forward to the beer!