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.
Re:JavaScript standards??? (Score:5, Insightful)
Trying to make stuff work with the various browsers is infuriating. Some things are the same, many things are not, or the behavior is just different enough to drive you insane trying to make everything work.
As I see it the problem is that the web is more and more becoming an application repository instead of static pictures and text (I know people have been saying this for years and it still applies). I mean that's the whole reason JavaScript and VBscript exist. The issue is that both JavaScript and VBscript are ad-hoc designs done by the major browser makers. We need standards like what ECMA is doing but ECMA doesn't go far enough. They need to define the GUI components and how they work in the scripting language. And the whole system needs to be made more powerful, currently the GUI functionality available in JavaScript/VBscript is substandard.
XUL sort of tries to solve this problem but again it's defined by a browser maker, good luck trying to get Microsoft to adopt that.
Re:JavaScript standards??? (Score:5, Insightful)
I disagree.
You cannot support everything, that is true.
You can do the following:
1) Identify a basic starting point (say where browsers had reached n years ago, accepting a high enough percentage of users fit that criteria).
2) Identify which features are commonly supported across those browsers (or commonly enough) and deem them "safe" to use.
3) Identify which other features are inconsistent but can gain a consistent interface through your coding. innerText may not be supported but that doesn't mean it's impossible to write consistent setInnerText/getInnerText functions that calls it directly for IE and then does more work to get the same result for other browsers.
4) Identify which other features are so inconsistent that there is no way you can write your own library to unify them (or add them).
5) Identify what fail-gracefully methods can be used for older browsers than your cut-off criteria.
With such an approach, you don't get all features of all implementations of JavaScript and DOM. You do however get a unified interface that allows you to use the majority of features on the majority of browsers and know that, even in the edge cases, the majority of those edge cases will fail gracefully.
Does it erase all of the differences? Absolutely not. But it does erase enough of them that the barrier for entry for many people now disappears.
Most people are concerned that they have to learn everything about all inconsistencies before they can code anything. They are concerned that, without that knowledge, even supporting the core browsers becomes impossible and they'll have a massive development cost testing for things they have no idea to look for.
A solution like the one above lets them have a list of things they can do, things they can't do, and a library of methods to unify the stuff in between. They know that, with that, they're pretty safe.
And that, as far as most users are concerned, is the unification they need - not absolute unification of every last detail.
Re:DOM is hell. (Score:4, Insightful)
Generally, the only reason to use DOM for output is when you need to be able to reuse the generated node tree in some other local function, and it is too expensive to use a DOM parser to read in XML data. Client-side in a browser, it is just about *never* too expensive to use a parser instead of code like yours.
When people do generate DOM like that the calls are generally more spread out inside application code where functions recieve a parent node to append children on.
Also, why would anyone create 2 <li> elements in inline code? Instead, it seems much more likely that someone would instead be looping over a result set and would be creating 1 <li> per loop.
You're looking at DOM all wrong. DOM is amazing for scanning through a parsed XML tree. Creating the output tree can be done in a hundred uninteresting ways.
Re:Browser delivers apps poorly (Score:2, Insightful)
I generally agree. Browsers started as e-brochure delivery systems but now that we want "real" GUI's, we find browsers have tacked on GUI stuff to this e-brochure framework in a clunky, indirect way.
However, the browser is becomming sophisticated enough that it can be viewed as a GUI assembler language in which other frameworks can be written on top of it. It has become a fat-client anyhow, so we might as well use it like one to get real GUI's.
The problem is variance from standards or each other, and versioning problems. However, I think we are now far enough along that we can start to put better GUI frameworks on top of the browser and have good ol' client/server-like apps. We can now think about bringing back the best of VB, Delphi, Clarion, and PowerBuilder like techniques without having to spoon-feed direct HTTP.
Re:JavaScript standards??? (Score:4, Insightful)
What the entire current JavaScript situation boils down to is the necessity to make libraries that wrap all these functions. Not just for functions that don't exist or don't work right, but inconsistencies in how they work. How about capturing the text that a user has selected? No browser in existance supports the three methods to get that so you have to roll your own that can do all three.
JavaScript is too diverse and has too many implementations to make your proposal work. A quick rundown:
So that's getting elements and modifying attributes. That's a bulk of what you do in DHTML. Verdict: not safe.
Again, a book cannot erase these differences. The only current solution is to make a giant library that handles all these specific cases, but that doesn't get rid of the differences in the language itself at all -- justs masks them from the user.
Re:Browser delivers apps poorly (Score:3, Insightful)
Or just distribute a copy of FireFox with your product.
If the customer isn't willing to install firefox, they're probably not going to install our 6GB of data either.
It runs fast enough to serve as an index for our 100,000+ term searchable database. You just have to know how to structure the index files and let the Browser's XML DOM implementation do most of the work for you.
Good webdesigners know the DOM (Score:2, Insightful)
Re:Suckage (Score:2, Insightful)
I'm correct in saying for the majority of us, if we want to learn a language we go looking for snippets dissect them get an understanding then add it to working knowledge. I have had such a hard time finding any 2 JS authors who agree on anything that I kind of just stopped persuing it.
The advent of those "article wiki" search engine traps did not help bring any clarity. What I mostly found were groups of people fighting over the "right" way to do it with no apparent victor. It wasn't apathy that stopped me it was total confusion. I wanted to learn only once if possible
Double suckage : Now my clients want inter-operable AJAX and I can't guess my way through it. I make server control panels and network monitoring applications. I *have* to learn this stuff.
It's not Javascript's fault for existing. It's my fault for not continuing to play with JS while waiting for w3c and others to glue everything together.
Ugh this is going to hurt.