Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

DOM Scripting 76

Simon P. Chappell writes "This is an unusual book in a good way. It covers a subject normally the preserve of geeks while being targeted at designers. Not a common approach, but one that Jeremy Keith pulls off rather handily. Mr. Keith is an active member of the Web Standards Project's Scripting Task Force; he not only knows how to script web pages, but he knows how to use that scripting to enhance the page's conformance to standards and even increase a site's accessibility. If you are like me, and have put off working with JavaScript because of the standards issues, then this book is our notification that those days are behind us. If you are a web designer who is interested in using dynamic techniques to enhance your site, but had feared the wrath of the standards police, this book is for you." Read the rest of Simon's review.
DOM Scripting
author Jeremy Keith
pages 341 (12 page index)
publisher Apress
rating 10/10
reviewer Simon P. Chappell
ISBN 1590595335
summary A tour de force that is destined to be called a classic.


I think that it's important to note that this is not a book about Ajax. For those of us feeling overly bombarded with Ajax this and Ajax that, this book is a delightful and refreshing read. Mr. Keith goes beyond the hype and brings us a strong explanation on one of the fundamental pillars of Ajax: working with the Document Object Model (the DOM of the title) using JavaScript. Without DOM Scripting there could be no Ajax, so this is an important addition to the library of any Web Developer who plans to create dynamic Web Applications. Who's it for?

According to the introduction: "This book deals with a programming language, but it isn't intended for programmers. This is a book for web designers. Specifically, this book is intended for standards-aware designers who are comfortable using CSS and XHTML." Mr. Keith is good to his word and his book is wholly targeted at web designers. That being said, I also found that the book was very suitable for programmers, myself included, who have been putting off using JavaScript in any depth. The Structure

The book's structure is fairly standard (no pun intended) and each chapter builds upon the proceeding one. The exceptions to this are the first and last chapters where the history of JavaScript and the future of DOM scripting are discussed, respectively.

Chapter two introduces JavaScript syntax and does a pretty good job considering that it is only 26 pages long. Chapter three then covers the Document Object Model. With the basic concepts of JavaScript and the DOM covered, the rest of the book proceeds to show us how to use them together.

Chapter four works through a basic JavaScript driven image gallery. This gallery is then revisited in chapter six where the JavaScript is upgraded to allow it to degrade gracefully according to the level of JavaScript functionality available in the browser and to ensure that the JavaScript is as unobtrusive as possible. Our final visit to the gallery example is in chapter seven where we learn to create markup on the fly and see how it can be usefully applied to enhance the gallery even further.

Chapter five looks at best practices for web design and how JavaScript and DOM scripting fit into that. Chapter eight takes a break from image galleries and looks at how DOM Scripting can help enhance our existing text content. Enhancement is also the focus of chapter nine, where the intersection and interaction of CSS and the DOM is explored.

Chapter ten is a little bit of fun, taking a look at animation through DOM Scripting. Chapter eleven, called "Putting It All Together" is a case study where a website is created for an imaginary band called "Jay Skript and the Domsters". The name may be corny, but the example is a wonderful display of starting with plain content and enhancing it using only standard compatible techniques. The book wraps up with an appendix of reference information of the JavaScript used in the book. What's to Like?

For a book that is not aimed at programmers, it is a great introduction to programming in JavaScript. Every concept is introduced clearly and the reasoning behind each approach is explained and the justification for it provided.

The book is very comfortable to read. The physical size, the typography, the design and the layout are all excellent. This is not surprising considering the target audience; excellent design is the minimum price of admission to the library of those in the design industry. What's to Consider?

There is very little that I did not like in this book. Although, I think that that it would be useful to point out again, that this isn't specifically written for programmers. If you know JavaScript well, this may not be the book for you. If you have extensive browser scripting experience this may also not be for you. And lastly, if you have no need, desire or interest in standards based scripting, this is absolutely not the book for you.

This is not a reference book. It will teach you a solid core of JavaScript suitable for working with the DOM, but do not think that it will teach you everything that there is to know about JavaScript. While the back of the book does have a small reference section, it is only for the concepts taught in the book. Website

Of course, the book has a website, available at domscripting.com. The site has an active blog and the finished version of the example site for "Jay Skript and the Domsters". Conclusion

This book deserves to be promoted to classic status immediately. It is written clearly, it uses only good principles of programming and adheres strictly to the appropriate standards. What a combination."


You can purchase DOM Scripting from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

DOM Scripting

Comments Filter:
  • DOM is hell. (Score:3, Informative)

    by SharpFang ( 651121 ) on Monday February 20, 2006 @04:38PM (#14763169) Homepage Journal
    Well, I don't know who was responsible for inventing DOM but I have some experience in writing using it, and today I had a refresher on how ugly it is.
    Consider the following piece of HTML:

    <ul type="square">
    <li><a href="#link1">Page 1</a></li>
    <li><a href="#link2">Page 2</a>(new!)</li>
    </ul>

    Let's rewrite it as DOM:

    var list=document.createElement('ul');
    list.createAttribute('type','square');
    var el1=document.createElement('li');
    var el2=document.createElement('li');
    var link1=document.createElement('a');
    var link2=document.createElement('a');
    link1.createAttribute('href','#link1');
    link2.createAttribute('href','#link2');
    var content1=document.createTextNode('Page 1');
    var content2=document.createTextNode('Page 2');
    var content3=document.createTextNode('(new!)');
    link1.appendChild(content1);
    link2.appendChild(content1);
    el1.appendChild(link1);
    el2.appendChild(link2);
    el2.appendChild(content3);
    list.appendChild(el1);
    list.appendChild(el2);
    document.getElementsByTagName('body')[0].appendChi ld(list);

    Of course you will likely pull link URLs from arrays, texts from some resource file, you won't be creating multiple variables to hold similar elements etc, but to create equivalent piece of document you will likely need to use something very similar to the above. (and it's still not the best. link1.remove(); ? No. link1.parentNode.removeChild(link1); link1.replaceWith(link2)? No. link1.parentNode.replaceChild(link1,link2);

    Do you already feel about the author of DOM specs the way I feel?
  • by possible ( 123857 ) on Monday February 20, 2006 @05:07PM (#14763299)
    Finally the designer guys will be able to learn basic standards compliant js and stop using the prefabricated, outdated do-not-touch messy scripts...

    Unfortunately, Javascripting with DOM is at least an order of magnitude slower than using the non-standard innerHTML approach. This is true of several browsers, including Internet Explorer. At my job, I recently completed an advanced AJAX-based web application interface that contains over 10,000 lines of new (re-usable) JavaScript APIs. DOM is great for small things but when you are rendering a dynamic sortable table with thousands of rows, DOM is absolutely out of the question. The innerHTML approach must be used (not sure why it renders so much faster, but it does).
  • Unfortunately, Javascripting with DOM is at least an order of magnitude slower than using the non-standard innerHTML approach.

    That depends on the browser, but i think you're confused. I did NOT mean to replace InnerHTML with DOM. Instead, i talked about replacing stupid code like this:
    if(document.all) document.all['something'] ... else document.layers['something']...


    with code like this:
    document.getElementById('something')...


    Anyway, the book is NOT about AJAX and complicated intranet websites filled with gazillions of forms, but about basic scripting.
  • Re:DOM is hell. (Score:5, Informative)

    by Bogtha ( 906264 ) on Monday February 20, 2006 @05:26PM (#14763385)

    Try this:

    var item, list = document.createElement("ul");
    list.type = "square";
    list.appendChild(item = document.createElement("li"));
    item.appendChild(d ocument.createElement("a"));
    item.lastChild.href = "#link1";
    list.appendChild(item = document.createElement("li"));
    item.appendChild(d ocument.createElement("a"));
    item.lastChild.href = "#link1";
    item.appendChild(document.createTextNod e("(new!)"));
    document.body.appendChild(list);

    That's almost half the size of yours. You're forgetting about the convenience methods and attributes that the DOM provides for HTML documents. As well as that, the various DOM methods have useful return values, so you can create and append elements without the temporary variables you use.

  • Sample chapter! :D (Score:4, Informative)

    by Spy der Mann ( 805235 ) <spydermann...slashdot@@@gmail...com> on Monday February 20, 2006 @05:27PM (#14763391) Homepage Journal
    http://domscripting.com/book/sample/ [domscripting.com]

    They talk about graceful degradation, using code like this:

    <a href="http://www.example.com/"
    onclick="popUp(this.href); return false;">Example</a>

    And about progressive enhancement, with code like:

    <p class="warning">
    Be careful!
    </p>

    instead of using font tags.

    Finally, a book which tells you how to do it right from the beginning.
  • Re:DOM is hell. (Score:2, Informative)

    by 6*7 ( 193752 ) on Monday February 20, 2006 @06:40PM (#14763834)
    "You're forgetting about the convenience methods and attributes that the DOM provides for HTML documents. As well as that, the various DOM methods have useful return values, so you can create and append elements without the temporary variables you use."

    Good advise, I just wonder why you don't follow it yourself?

    You are "hiding" allocation like:
    list.appendChild(item = document.createElement("li"));
    which to my knowledge (and a little testscript) equals:
    item=list.appendChild(document.createElement("li") );

    This is much more readable in your example, now it suddenly becomes very clear where the object, item is a reference, to is changed.

  • by FloridaFun ( 956047 ) on Monday February 20, 2006 @10:12PM (#14764865)
    Take a look at this AJAX DOM Scripting web site http://www.gendivide.com/ [gendivide.com] . It appears to offer alot of dynamic functionality. Very fast. Doesn't like old people though.
  • Re:DOM is hell. (Score:2, Informative)

    by hobo sapiens ( 893427 ) on Monday February 20, 2006 @11:08PM (#14765062) Journal
    Fair enough, but keep in mind that you will seldom need to write that code. I can think of two occasions where I have had to write that much javascript to create nodes (and I do 40 this hours a week), and those were places where I had a form that needed to be expandable to allow users to add any amount of records needed. Then I discovered nice functionality like cloneNode, which does just what it sounds like, copies a node into a var. You can then use insertBefore to place the new node on the page. Usually, I write html code and just clone it as needed.

    Therefore, I suspect that your dislike for Javascript stems from the fact that you may not be familiar with all of its methods and properties. I use this reference [mozilla.org] frequently. Yes, it is Mozilla, but most of the things here are standard. I'd learn some new methods and properties and then see what you can do with javascript. No, it's not the answer for everything but it can be quite powerful if used correctly.

    I use a lot of Javascript in the intranet environment, which consists of IE6 (sadly), Fx, and Opera. On the internet, yes you are more limited. But as long as you provide alternate, though perhaps less convenient, ways of doing all of the important stuff on your site, you will be OK. Just don't rely on it for _critical_ validation, core functionality and you are OK. For improving usability, efficiency, and user experience in general it is great. It is what it is, but it doesn't have to be as complicated as you make it seem.

    Hope you find that link helpful!

    --
    I am not an actor, but I play one on TV!
  • by great throwdini ( 118430 ) on Tuesday February 21, 2006 @12:17AM (#14765362)

    They talk about graceful degradation, using code like this:

    <a href="http://www.example.com/" onclick="popUp(this.href); return false;">Example</a>

    Not to be too picky, but that onclick should really run more along the lines of (as a start):

    onclick="return popUp(this.href)"

    Where popUp() returns true or false depending on whether it actually fired properly. One can never be too careful...

  • by multipartmixed ( 163409 ) on Tuesday February 21, 2006 @03:37AM (#14765969) Homepage
    Sooo.... you meant that now designers could stop writing code that breaks on anything but IE and Netscape 4?

    The respondent rightly points out that using the W3C DOM still is not the best option for inserting nodes; innerHTML is much faster. To this respondent - the reason is simple: 1,000 row insertions done in the DOM requires 1,000 separate tree insertions and modifications under JavaScript control, marshalling and returning these objects back to the interpreter, blah blah blah. The innerHTML method simply assembles everything as a string first (which is much cheaper!), generates a tree, and inserts the root of the new tree into the document.

    (note, above paragraph somewhat simplied).

    My option? W3C should add a "parse" method, which would parse a hunk of HTML and return a handle to the root node for you to insert yourself.
  • by steinnes ( 774991 ) on Tuesday February 21, 2006 @07:56AM (#14766595) Homepage
    Parent is right, should get modded up.

    The difference lies in the fact that each DOM call results in the whole thing being rendered, whilst the innerHTML method just requires the browser to read a chunk of HTML and render it once.

    Perhaps objects should have some sort of render() method, and a possibility of auto-rendering which could be toggled? Thus avoiding rendering of objects being manipulated after each change, etc? Oh well, it's fun to dream..

Be careful when a loop exits to the same place from side and bottom.

Working...