Slashdot Mirror
Dynamic HTML The Definitive Reference (2nd edition)
What's in the book?
The book is not an introduction to DHTML but it does have an 183-page section on Applying DHTML that covers not only the current state of the art but also gives clear guidance in making use of all the features. The guidance is of a good enough standard that a firm's Quality program could simply cite this book as the basis for the web development standards that a team adopts. Goodman makes it very clear that he is not going to discuss the DHTML that Navigator 4 introduced, the <layer> tag and JavaScript style rules, but points out that they are covered in the first edition should you really need to know.
The layout of the book is the same as the first edition, with the reference sections divided into HTML, DOM (Document Object Model), CSS (Cascading Style Sheet) and JavaScript. A new section for Events also makes an appearance. The reference sections on HTML and DOM have sub-sections that precede them on the shared attributes of all elements. These are particularly useful and I think should be committed to memory.
There is also a very curious Cross Reference section that has an HTML/XHTML attribute index and a DOM property, method and event handler index. It takes each HTML/XHTML attribute and shows which elements support it and then each DOM scriptable object property, method and event and which objects support it. I'll confess I've never had any call to use this section but I can see how it could come in handy -- and it hardly takes up much dead tree.
The upper limit of standards coverage is HTML 4.01, XHTML 1.1, CSS Level 2, DOM Level 2, and JavaScript (or ECMAScript) 1.5. The browsers considered are IE6 (Windows), IE 5.1 (Mac), Netscape Navigator 6 and 7 and Mozilla 1.0. Opera is also mentioned in the section on Applying DHTML in that it mostly follows the IE DOM. The timeline for any element can go back as far as HTML 3.2, Navigator 2 or IE 3.
As you would expect, there are some useful appendices: Color Names and RGB Values, which I expect to be using more now as sites are required to meet Accessibility guidelines; HTML Character Entities, for when you don't have a copy of Macromedia Dreamweaver or when your favourite HTML editor doesn't have a complete list; Keyboard Event Character Values, for your scripts when you want to catch all those key presses; Internet Explorer Commands, which along with the MSHTML.dll can allow the creation of a very neat content editor quite quickly and easily; and finally, an HTML/XHTML DTD Support cross-reference that may help catch validation errors as you move from an HTML 4.01 Transitional DTD to a full-on XHTML 1.0 Strict DTD.
What makes it worth having?The quality of Danny Goodman's writing is both technically accurate and easy to read. The clarity and lack of fluff is good, but there is no skimping on detail where such is needed to illuminate a point. Let's face it: web development is not as complex as most software engineering or systems development tasks, but it is a discipline with quite a wide base, reflected in the 1400 pages of this tome. I wouldn't trim any of it, however, and I expect that after about a year of use I will have referred to a good proportion of the contents. Take, for instance, Goodman's estimate that there are more than 15,000 unique instances of properties, methods, and event handlers supported by numerous document objects and you get an good impression of the size of the documentation required.
The book could be regarded as two books in one: There is the Applying DHTML book and the Reference book. The best things about the reference sections are the excellent descriptions, the clear little examples, and especially the quick summary of where you can expect these things to be supported. Referring to this book is the simplest way to avoid going down the proprietary browser extension cul de sac.
The Applying DHTML section is worth reading all the way through. It is great for getting yourself into the various technologies and seeing how they are meant to work. There are interesting points made on how each of the technologies are evolving. There's material contrasting the various DOM implementations and there are chapters on style sheets, positioning in CSS, making the content dynamic (of course, this is what DHTML is all about, after all) and scripting events.
There is a very useful cross-platform API for DHTML (which can be downloaded as a zip file along with the other examples from the book on O'Reilly's web site). I've used the version from the first edition quite a lot, and I've used the new version in my most recent work. It doesn't rely on browser version sniffing, but rather on object detection, which is explained with some examples, and can be easily extended to handle any DOM call you may wish to make. The API is especially useful for any CSS positioning tasks you may have. Goodman also goes over other strategies you can adopt to make your sites cross-platform, such as page branching, designing for a common denominator, and some other, neater, solutions.
There isn't anything on Accessibility other than a single paragraph drawing your attention to the Web Accessibility Initiative (WAI). DHTML and Accessibility could be considered inimical but that isn't the case and I'd perhaps have liked to see this elaborated on with some suggestions on how to achieve an Accessible site while still using DHTML. In practice, however, I've found it easy to meet the Priority 1 checkpoints (or A rating) set by the WAI even with a complete DHTML site so perhaps this is not really an issue.
I find this book really useful. I can't imagine any web developer doing without this book and managing to produce a good cross-platform solution, and I also can't imagine that developer needing any other texts on any of the technologies covered here. I certainly don't have any others on my desk today.
The O'Reilly web site has a complete Table of Contents available. You can purchase Dynamic HTML The Definitive Reference from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
... no matter how good the book is (and it probably is, I'm not meaning to say it isn't), doing good html is really hard / complicated. A good book isn't going to automatically mean you master it - you need to practice like mad, read the source code for websites, create websites, have common sense, a decent understanding of the human-usability thing (not easy), and be prepared to do the tedious work that is typing out html once you've mastered the skill in the first place.
From where I look at this, the market is actually quite different.
I would say the vast majority of sites I have personally ever worked on have been internal projects. Using web standards to create a front end for an application is a very appealing idea. After all, if one decides to turn the application into a distributed app, there is a lot less work.
This is where I see the advanced topics of DHTML and JavaScript being used, not in the latest homepage of some stranger. Probably not even in the latest shopping site, which was probably designed years ago for ultimate compatibility.
As an aside, with Mozilla (the engine) gaining in popularity as an application framework, I can only see these topics gaining even more relevance.
The same thing can be said about any book covering just about any language.
"Let's face it: web development is not as complex as most software engineering or systems development tasks"
You obviously never had to cope with developing a complex web application. When done right, it's a task far more complex than "conventional" software engineering.
Rich client-side interface doesn't mean a mouse-cursor tracker or validating your form on the client-side. It means letting the client side do ALL your application logic and interface, seperately. And let the server do the dumb job of validating, saving and returning raw data that can be handled by client-side custom components or logic-flow.
Not as complex? No, even more complex, if you're doing anything worthy.
Anyone who develops sites for corporates is going to be using DHTML to make it appealing and easy to use. I develop internet apps for a living, and I use DHTML all over the place in my development. You can make some VERY effective user interfaces with DHTML... I've used it in my sites to create extremely flexible/dynamic forms that pass sophisticated information in a single form that would require 5-6 round trips to the server without it. You quite obviously have no idea what you're talking about. Perhaps you should stop spewing crap and learn a little about the subject before you mouth off.
-1 Uncomfortable Truth
this is a result of people confusing Micro$fot with the W3C.
IE supports both the "right" way and an M$ only way of doing things.
So it's quite easy to write one set of code that ie5+ and Mozilla use to dothe same thing. However, thanks to certain organizations promoting the other way of doing things, some web devs write code that only works in IE.... which then perpetuates taht "all other browsers but IE suck" because "wow, look how good it works in IE but it breaks in _____."
Department of Homeland Security: Removing the rights real patriots fought and died for since 2001
Are people *still* pushing DHTML? Any standard that incorporates client-side JavaScript sounds like a bad idea to me. Client-side JavaScript is a pain to implement and has high maintenance costs.
You get plenty of bang for your buck with HTML or XHTML with CSS. If you need business rules, stick 'em on the server.
And don't waste time learning JavaScript! Your time is better spent learning PHP, Java, Python, you name it. You can't use JavaScript anywhere else.
-Ed
I use IE6 to cruise the web. Given the all the security holes and patches, I'll be damned if I say yes to "Scripts are usually hamless. Ok to run?"
Even a site like the NYtimes runs under lockdown on my machine. Though I trust the web designers at the Times not to be malicious, I don't think they can secure their site against an attack that sneaks a malicious script onto their site. Same thing is true of internal web pages.
Not as long as you follow the current standards (DOM). If you do that, both IE and Mozilla has rather good "DHTML" support. It's funny that there's a way to write decent cross-browser pages that's dynamic and all that and that this way is even standardized, while many web developers *still* refuse to realize facts and continues to struggle with Microsoft's document.all model, having to disable parts of pages to make them cross-browser, etc. Is it lack of education? Brainwashing?
The site I'm thinking of is Citibank's credit card management section
Yeah, and just by looking at the source code at their login screen I see tons of non-standard DHTML code so it's no surprise it isn't working well at other browsers than IE.
I'm talking about this:See that frm.USERNAME rubbish?
If they had just changed that fragment to this:.. and it might have worked a lot better on Mozilla (while still maintaining 100% compatibility with IE! *gasp*). Look above at the incredible effort spent too.
Beware: In C++, your friends can see your privates!
Then they have to suggest using something like this:Can you see the maintenance you'd need to do to make it cross-browser compatible?
The alternative is DOM where you can use common code for all browsers that support DOM. Considering that the standard has been around for years and is supported rather good by all current browsers, it's surprising that there's enormous amounts of sites around that teach the aging "version 4" coding philosophy. It's the philosophy behind those hideous IE-specific pages that might have *some* Netscape support in but break when you use a browser/browser version the coder didn't expect or didn't exist at the time the page was coded.
Beware: In C++, your friends can see your privates!
...buy the book here, and support stores that protect their customers' privacy.
"If you were commissioned to design a new 8-lane, divided highway, would you set the speed limit at 30 mph, to ensure that those who choose to drive around in Model T's can keep up with traffic?"
This isn't a very good analogy. When you go to a non-dhtml web page, are you dissapointed, or othwise negatively affected specifically because they aren't using DHTML? Your analogy states that everyone would be negatively affected by someone's choice not to use the latest and greatest.
I will counter your analogy with another bad/wrong analogy:
If you were commissioned to design a new 8-lane, divided highway, would you make all the road signs fly from one side of the road to the other? Would you have "Hit the Monkey and Win $20" interactive highway advertisements? Would you make drivers have to drive over a certain spot to see certain signs?
It all depends. Most of the things in my bad analogy wouldn't be good ideas. It just depends on the audience, and what you are trying to convey. Not using the latest and greatest isn't a 100% sure sign that a site will be a bad experience. That depends on the skill and intent of the designers/programmers, not on the technology they use.
"... the advance of civilization is nothing but an exercise in the limiting of privacy" - Janov Pelorat
"Well, that's certainly a pretty low denominator! But let me ask you this. If you were commissioned to design a new 8-lane, divided highway, would you set the speed limit at 30 mph, to ensure that those who choose to drive around in Model T's can keep up with traffic?"
Arrrgh I'm sick of people arguing with metaphors! Feels like I'm watching an old episode of Star Trek!
There are reasons to not rely 100% on the imagery of your site. For example: I went on a business trip, the modem connection was awful. I turned off images in Opera so that I could browse the web in a reasonable amount of time. The reason why that works is because most of the sites I went to had documented what each of the images are.
It's a matter of accessibility, not speed. If you support blind people, for example, then your website doesn't suddely slow down to 30mph as your poorly chosen metaphor suggests.