![Programming Programming](http://a.fsdn.com/sd/topics/programming_64.png)
![Books Books](http://a.fsdn.com/sd/topics/books_64.png)
![Media Media](http://a.fsdn.com/sd/topics/media_64.png)
![The Internet The Internet](http://a.fsdn.com/sd/topics/internet_64.png)
![Book Reviews Book Reviews](http://a.fsdn.com/sd/topics/bookreview_64.png)
![IT IT](http://a.fsdn.com/sd/topics/it_64.png)
![Technology Technology](http://a.fsdn.com/sd/topics/technology_64.png)
DHTML Utopia 154
Bruce Lawson submits the review below of Stuart Langridge's Excellent guide to creating dynamic web pages; scalable and sensible., writing "Don't be put off by the title: the DHTML here bears no resemblance to the stupid Web tricks of the late 90s that allowed animated unicorns to follow your cursor or silly Powerpoint-like transitions between Web pages." Read on for the rest.
DHTML Utopia: Modern web design using JavaScript and DOM | |
author | Stuart Langridge |
pages | 300 |
publisher | Sitepoint |
rating | 8 |
reviewer | Bruce Lawson |
ISBN | 0957921896 |
summary | Excellent guide to creating dynamic web pages; scalable and sensible. |
This book is the opening salvo in the latest battle in the Web Standards war -- the battle for unobtrusive JavaScripting, or Unobtrusive DOMscripting as many call it, in order to rid it of all the negative connotations that "DHTML" and "JavaScript" bring. Combined with the non-standard XMLHttpRequest object, it's sometimes referred to as "Ajax". Terminology aside, though, what are the substantive differences between the old-skool and the "modern" of the title?
- Graceful degradation. A great example of this is Google Suggest in which the DOMscripting enhances functionality by making the page feel more responsive, but if you don't have JavaScript for some reason, the page still works.
- Separation of structure, presentation and behaviour. The DOMscript deals with the behaviour in the same way as CSS defines the presentation in the brave new Web standards world, and the three remain separate. The html has no JavaScript in it at all -- everything is handled by in separate code files.
- No browser sniffing. This aims to future-proof code by testing for features rather than sniffing for browser name and version. So, before using the TimeTravelCureCancer method, the current browser is tested to see whether it's supported. If it is, the script continues. If it isn't,the script silently fails with graceful degradation.
Theory sounds cool -- how's the damn book?
I was pleasantly surprised by how quickly the book gets to work. Even before page numbering begins, the introduction has a lucid and compelling argument for using HTML 4.01 rather than XHTML as the markup language of choice.Chapter 1 has a brief (6-page) overview of the importance of valid code and separating presentation into CSS, and a short description of the unobtrusive nature of Langridge's scripts: no script in the mark-up at all; instead, the .js files contain "event listeners." The reasons why this is desirable are promised later.
Chapter 2-4: The basics
Now that document.write in the html is no longer needed, you need to know the "proper" way to add text or elements to a Web document. So Langridge gives us a tour of the DOM, showing how to walk the DOM tree and create, remove and add elements to the tree. It's methodical, and by the time I was beginning to get a bit tired of theory and thinking that you'll have to prise document.write out of my cold, dead hands, we get an "Expanding form" which allows us to expand a form ad infinitum to sign up as many friends as you want to receive free beer, without ever going back to the server. (You can see such a thing in action in gmail, when you want to attach multiple documents to an email).I started to warm to the author and his style. 33 pages into the book, and we get a real-world working example to examine (I like my theory liberally garnished with practice). I also feel a kinship with authors who fantasise about mad millionaire philanthropists giving away beer.
By chapter 3, we've really got going. Apart from one rather pedantic edict (the event is mouseover, the event handler is onmouseover and we should separate the nomenclature, even though it makes no practical difference), the focus here is on real-life browsers. And, as we all know, in Web dev books, real-life browsers means grotesque exceptions to our ideal-world rules .Strangely -- and oddly satisfyingly to this PC user -- the culprit isn't only the perennially despised IE/ Win; shiny Safari comes in for a good bit of stick!
The real-world example here is a data table that highlights the whole row and column of any cell that's being moused-over. Now, in any modern browser except for IE/ Win, the row could be given a hover pseudoclass (IE/ Win only allows :hover on anchors). But as there is (weirdly) no HTML construct for a column, this effect can only be achieved through DOMscripting. What the script does is to dynamically append a class name to every cell in the row and column at run time -- and the pre-defined CSS file determines the styling of that class.
Herein lies an advantage in Unobtrusive DOMscripting: you could just take this script and plug it into a Web site without changing any of the html (except to add a link to the script file in the head). But the script is relatively complex for a newbie to code, and for the techniques to be widely used, I suspect that the billion old-skool cut'n'paste JavaScript sites will need to be replaced with a single, canonical library of modern scripts for people to cut and paste from. For those who find CSS challenging, JavaScript is probably even more complex. .
Chapters 5 - 7: blurring the division between Web UI and application UI
It's a truism that the Web has set back UI development some years -- in fact, back to the old dumb-terminal paradigm of filling in a screen full of data, pressing the button to send it back to the mainframe and waiting for the next page to be sent -- or the old one returned with errors noted.Langridge shows that we can make the experience smarter than this, going beyond the traditional JavaScript client-side validation interactivity by adding animation to allow text to fade in and out over time, styling tooltips to be sexier than the default yellow box and which can gently appear into view rather than the browser default on/ off state are examples that struck me.
When I first read these, I thought they were cheesy gimmicks -- the modern equivalent cursor-following unicorn -- until I considered more deeply and realised that many of the UI elements that we enjoy in modern desktop apps are precisely these small, cosmetic effects: abrupt transitions, lack of transparency, sharp edges to UI widgets all feel like old operating systems or clunky Web pages.
It's not all touchy-feely; we get auto-complete text entry, degradable calendar pop-ups, flyout menus and lessons in OOP, encapsulating code for re-usability, and avoiding Internet Explorer memory leaks.
Chapters 8- 10: seamlessly working with the Server
So far, so client-side. Where Unobtrusive DOMscripting really gets developers juices flowing is the ability to communicate with the server without obviously refreshing the page. Chapter 8 takes you through a variety of methods. Some, like the hacky iframe method or hideous 204 piggyback method are so gruesome that I breathed a sigh of relief loud enough to wake the cat when I finally turned the page to read "XMLHTTP". This method (which is non-standard and introduced by Microsoft) has ushered in the Next Great Web Thing: asynchronous communication with the server. Langridge walks through using the Sarissa library to make a user registration form that checks whether the user name you choose is taken, and if so, suggest some alternatives without refreshing the page.There's a lot of unresolved accessibility problems with the Ajax method (how does a screenreader alert the listener to the fact that something new has appeared on the page? How do they navigate and hear the new stuff in context?) and while it is laudable that Langridge notes these issues exists, I'd hoped he would have suggested some solutions. He doesn't, but as he's a member of the Web Standards Project's DOMscripting task force I'm guessing it's being worked on.
The project that really kicks ass in this section is a file manager, like the one in most people's Web site control panels, where you can actually drag and drop the icons, like an operating system, and the server does the work. Langridge carefully goes through all of the steps, all of the pitfalls and all of the code needed to make this happen in any modern browser.
It doesn't take a lot of imagination to realise just how this could revolutionise the Web experience. Drag and drop products into a shopping cart. Drag the shopping cart to the checkout icon. Moving money around bank accounts in some integrated internet banking application. The possibilities are huge.
Conclusion
The whole technique of unobtrusive DOMscripting needs further research before it's ready for prime time -- particularly from an accessibility point of view, but then as an accessibility bore you'd expect me to say that. I think it's beyond question that there's ideas in here that radically enhance the usability of Web-based applications by making them more intuitive and more like the desktop drag-and-drop interface we know from our desktops.This is a good-humoured, thoroughly-researched book that combines theory with practical learn-by-doing examples. To this reviewer, the code appears scalable and sensible. This book is never going to appeal to the quivering aesthete designers -- probably because it's fundamentally about code. But precisely because it proposes a complete separation of code and design, it facilitates the advancement of the Web.
You can purchase DHTML Utopia: Modern web design using JavaScript and DOM from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Unicorns (Score:5, Funny)
If my boss reads Slashdot I think I know what I'll be asked to add to the corporate website tomorrow morning..
Re:Unicorns (Score:1)
Re:Unicorns (Score:2)
Re:Unicorns (Score:2)
http://bunnyherolabs.com/adopt/ [bunnyherolabs.com]
http://byjoni.com/blueunicorn.html [byjoni.com]
Re:Unicorns (Score:2)
Capability Sniffing does not work in all cases. (Score:1)
Here is an example that I ran into of how capability sniffing is not enough:
The add method on a select element exists in IE 6 as well as Firefox. However, in order to a
Birth of Ajax (Score:4, Informative)
Ajax: A New Approach to Web Applications [adaptivepath.com]
Re:Birth of Ajax (Score:1)
A
Why do it yourself? (Score:5, Interesting)
Interesting technology, but too easy to use REALLY badly. It would have been nice if the the book had covered how to build SOLUTIONS using DHTML, rather than focusing on how an individual can use it.
Re:Why do it yourself? (Score:2, Insightful)
The challenge with Ajax, and complex DHTML is that a slight error produces big problems.
I think the challenge with any program is that errors produce problems. That'
Re:Why do it yourself? (Score:2)
I think that slight errors in any framework or programming language can cause big problems and not something particular about AJAX.
Re:Why do it yourself? (Score:2)
Did you RTFA or even the post? An Open Source cross-browser implementation called Sarissa [sourceforge.net] does that.
Sarissa Oveview:
Re:Why do it yourself? (Score:2)
Regardless of theory (Score:1)
Please... Don't (Score:4, Insightful)
Expect to see flooding the internets(tm) over the next few months annoying over-use of AJAX in every single way that programmers can -- even if they don't need to.
Re:Please... Don't (Score:1)
I'm working on something like that - check this out: https://inkjet.ie/shopping [inkjet.ie] cart?catid=22
It's not quite perfect yet, and is not accessible yet, but the functionality is there.
When I'm happy with the cart's functionality, I'll be writing an article explaining exactly how it was all done, and what problems I came across while building it (uploading files through AJAX is a pain, for example).
Ruby on Rails (Score:2)
Re:Ruby on Rails (Score:2)
How about explaining your statement.
Give a small example.
Saying RoR is sweet doesn't help the Ruby community or the Slashdot community. I could say using modperl or IIS/ASP is sweet for AJAX but, it would serve no purpose.
Why not add a comment that informs and helps the reader?
Why not respond to this post saying how Ruby on Rails and AJAX can work together? That might provoke interesting and informative dis
Re:Ruby on Rails (Score:3, Informative)
Ruby on Rails has clean, built-in support for template code that generates the client-side Javascript for using the prototype.js library.
It makes it next to trivial to create, for example, Google Suggest text fields because the developer focuses on using Ruby syntax to indicate the server action to invoke, based on what client behavior, and what to do when the results come back to the browser. The annoying little details
Bookpool has it cheaper than bn.com (Score:2, Informative)
Re:Amazon has it cheaper than bookpool (Score:1)
Re:Bookpool has it cheaper than bn.com (Score:1)
Must be why it's so much cheaper.
I give up (Score:2, Interesting)
Re:I give up (Score:2)
Let's drop DHTML like the steaming sack of decaying garbage it is and focus on writing quality, structurally sound, and accessible code.
Re:I give up (Score:2)
I'm sorry, that makes no sense. DHTML has nothing to do with browser pissing contests (those just made it hell to implement.) DHTML is the aggregation of (X)HTML/Javascript/CSS to make a page less static.
The lack of standards has made pretty much anything implementing DHTML a steaming pile, but DHTML itself is just a technique. And if you're willing to ignore four year old browsers, the state of affairs has gotten to the point that you can write decent code properly separated from your presentation.
Re:I give up (Score:2)
Re:I give up (Score:2)
As long as you don't need to support 4-5 year old browsers, XMLHttp works fine. If you need to support 4-5 year old browsers, either force your users to upgrade (by not s
Re:I give up (Score:1)
Websites should use the freaking standards. Doesn't ANYONE remember the browser wars?
Re:I give up (Score:1)
And I wouldn't call it a major browser by any means, I don't know anyone who uses it...
Re:I give up (Score:2)
Of course you won't find any Windows users who use it! Duh! But it's the default browser for KDE, which I understand is a wildly popular desktop for Unix.
As for XMLHttpRequest, I only know what I've been told. And I've been told that the only reason all the new Google apps don't support Konqueror is the lack of that non-standard item.
Re:I give up (Score:2)
XMLHttpRequest is available, in a mostly identical form, in the current stable versions of Internet Explorer, Gecko-based browsers (including Firefox, Netscape, Mozilla, and Camino), Opera, an
Re:I give up (Score:2)
The other kind of standard is the formal standard. It does NOT need to be a government m
Re:I give up (Score:2)
Is your complaint that XMLHttpRequest isn't documented? I argue that it is [microsoft.com].
RSS has been through several revisions. Is 2.0 a "formal standard"? If so, what makes XMLHttpRequest different? If not, wh
Re:I give up (Score:1)
simple (Score:2, Funny)
I think slashdot is smart for sticking with terribly invalid HTML 3.2. In another year or so, they'll be leet as fuck.
I'll be lanching my new markup language soon, which is going to be so leet you'll shit your friends' pants.
<web
Re:simple (Score:2)
You mean Powered by Bloxor [bloxor.com]!!
Re:simple (Score:1)
Re:simple (Score:2)
Re:simple (Score:2)
Re:I give up (Score:3, Informative)
Personally, I don't mind using XHTML 1.0 as text/html, as although it's not quite "ivory-tower" perfect, it's still IMHO a little cleaner and more elegant. Either way, (X)HTML+CSS still beats the living daylights out of "any-old-HTML + tables".
Re:I give up (Score:1)
will serve application/xhtml+xml to any client that claims to accept it. Mozilla does, IE doesn't. Safari just sends */* as its accept string, so it gets text/html.
Re:I give up (Score:2)
Content negotiation is an old concept.
It also reduces your cache hits, increasing server load and bandwidth costs, and slowing down your website.
Your code is broken, BTW. You need to transmit a Vary header when you vary content based upon request headers, otherwise you can screw up caches so they send application/xhtml+xml to Internet Explorer.
I see (Score:2)
Re:I give up (Score:2, Informative)
Read more of Stuart's thoughts on his website:
http://www.kryogenix.org/days/2002/11/28/whats [kryogenix.org]
http://www.kryogenix.org/days/2005/02/21/xhtmlHtm
browser problem (Score:4, Interesting)
A lot of the annoyance of 'web apps' comes from the fact that browsers can't just refresh a simple tag on the page from the server. They have to re-render the entire page, causing a jarring visual experience for the user.
Browsers should be able to realize that since the url is the same, diff the previous stream, and the current one, and modify the current page inline.
As it stands now, web developers have to jump through a lot of hoops to get that sort of functionality. They shouldn't.
Re:browser problem (Score:2)
Re:browser problem (Score:1)
Re:browser problem (Score:2)
Most of the slowness with a page refresh is typically network latency and bandwidth bottlenecks. Browser tricks won't help with that.
Re:browser problem (Score:1)
Yeah, like:
Chapters 8- 10: seamlessly working with the Server
Where Unobtrusive DOMscripting really gets developers juices flowing is the ability to communicate with the server without obviously refreshing the page. Chapter 8 takes you through a variety of methods. Some, like the h
Re:browser problem (Score:2)
Why don't you submit the code to re-parse the DOM tree and update the page in-line? You could submit it as BSD-licensed code so all browsers could use it, you would be famous!
AJAX is _really_ not that hard as another poster pointed out. S
Re:browser problem (Score:1)
Plus, with larger pages and/or slower networks a full refetch would become a lot slower than DOM modifications.
Re:browser problem (Score:1)
Stupid Web Tricks From The 90s... (Score:1, Offtopic)
Wow! I been running my website [creimer.ws] since 1998 and I never came across a web book with stupid web tricks like that. Did I missed something?
MOD PARENT DOWN (Score:1)
Re:MOD PARENT DOWN (Score:2)
Re:MOD PARENT DOWN (Score:2)
It's still just stupid hackery (Score:2, Interesting)
why not (Score:2)
But, whats wrong with building rich applications for the browser? Is this somehow more evil than hard to maintain, bloated, crappy VisualBasic/Swing/Delphi/Powerbuilder applications that will be very platform specific?
A mess of code will happen in any language on any platform. Its up to the developer to prevent it.
The browser is just a tool. Why not exploit that its much easier to build/test an app for a handful of browsers tha
To me there are three deal killers in Web Dev (Score:2)
2. Any user action that alters state (and often even those that do not) require a round-trip to the sever, including #1.
3. Creating a quality UI has become a voodoo-like thing where you have to rely on all kinds of unwritten laws because CSS2 is not flexible enough beyond simple document formatting. Place a login UI in the center of the screen in XHTML1.1 Strict without using Javascript
Good review! (Score:2)
I think AJAX et. al. could be a bit of a diversion though from the ideals of "unobtrusive scripting" though. Many sites using XMLHttpRequest and similar techniques aren't easy to degrade in older, non-JS-supporting browse
Congratulations on your site (Score:2)
Keep up the good work.
Regards,
Re:Congratulations on your site (Score:2)
Take me to XML Island (Score:2)
Here's a demo [w3schools.com] (use IE5 or later). I figure they must be in use somewhere because there's even a Mozilla article [mozilla.org] on getting them working in Mozilla.
Re:Take me to XML Island (Score:1)
Kindof like XSL/XML/CSS display bullshite circa 2003:
In the Firefox/Mozilla camp, CSS was the only way for a long time to manipulate XML for display.
In the Internet explorer camp, XSL was the only way to manipulate XML for display.
Hopefully we can get XML to display with CSS 100% in IE7, cause you can't in IE6. I think Mozilla has XSL embedded in the browser now (I hope).
DHTML popup ad hell. (Score:1)
Re:DHTML popup ad hell. (Score:2)
solution part 2 [pierceive.com]
For your enjoyment (Score:2)
Animated Unicorns. [chrismullins.net]
Drag and drop example. (Score:2)
Extreme DHTML? (Score:1)
http://assembly.mbnet.fi/asm05/compos/browser_dem
If you use 800 x 600 resolution you can see it fullscreen. It placed third in the Assembly 2005 demo competition. IE recommended for watching, though it runs on Firefox as well.
Re:Extreme DHTML? (Score:1)
IE recommended... now there's something you hope not to see.
Re:Extreme DHTML? (Score:1)
Re:Extreme DHTML? (Score:2)
Basically, this demo uses javascript and DHTML in some interesting ways, but the code behind the scenes is pretty "standard".
Essentially, they render the sides of the cube using a scanline renderer, which simply renders the sides as two separate triangles, built by drawing horizontal lines top to bottom (hence "scanline"), with the widths dependent on the slopes of the sides of the polygon (triangle). This is accomplished via a si
Two words... (Score:2)
This is very impressive - sorta runs under Mozilla (had to load index2.html directly (for some reason the popup redirect in index.html didn't work) - and it was kinda jerky on my box (but my box isn't the latest, greatest, or anything like that) - but I am impressed nonetheless! I really loved the ending spinny-twisty thing! Great job!
Separate this... (Score:1)
My pages are nothing but a single, empty html and body tag... and EVERYTHING is dynamically cross format focused in Nashian triplicate (yeah! it goes there) on the back-end.
You cannot touch this!
DynLayer is the way to go (Score:1)
Re:DynLayer is the way to go (Score:1)
Lots of reasons.
Firstly from a philosophical stand-point it is always best to have more than one way to do things.
Secondly because not everyones' experiences of dynapi are positive.
I found it:
1.) awkward to use.
2.) able to cause even well specced machines to grind to a halt.
3.) a pain to extend.
4.) clunky, overwrought, fairly incomprehensible.
Also I'm not sure that it entirely separates t
table of contents? (Score:2)
Neither B&N nor Amazon see fit to display the TOC for this book. If somebody knows of somewhere it's listed could you post that here? I'd especially like to know if 1/3 of the book is appendices we don't need.
Good review, BTW. Too bad about the book's cover. What's up with that? Although it did make me think of the Brazil dream sequences. Perfect for those dreary winter afternoons in the cubicle farm.
Re:table of contents? (Score:1)
I just bought this book (Score:2)
IMO, the layout of the book is good and it's written well - from first glance anyways.
Can anybody point out any strong online resources on AJAX development? I guess it's not that difficult to grasp, but I would like a little more of a foundation.
Re:I just bought this book (Score:1)
That Google Suggest link (Score:1)
AJAX (Score:1)
I hear a distant rumble... (Score:2)
... as a herd of corporate lawyers stumble against each other to file a new non obvious technology: drag & drop... but on the internet!
It doesn't take a lot of imagination to realise just how this could revolutionise the Web experience. Drag and drop products into a shopping cart. Drag the shopping cart to the checkout icon. Moving money around bank accounts in some integrated internet banking application. The possibilities are huge.
what is so great about "unobtrusive" ? (Score:2)
Why not use the full power of DHTML and build applications that totally rely on it?
The one piece of the Ajax puzzle that I could see being optional is XMLHttpRequest, as it is only a de-facto standard. ECMA script, CSS, and DOM are standards, and the browsers can be expected to support them.
Attempting to maintain support for non-conforming browsers s
Re:Save Some Money (Score:1, Informative)
No, pay attention. (Score:2)
--grendel drago
Re:No, pay attention. (Score:3, Insightful)
Since it doesn't change the price I pay Amazon, I'm afraid that I just can't work up any rightous indignation about it. In fact, since (or maybe if) he's saving folks $10, I'd say it's pretty good if a few quarters land in his beer fund.
Re:Save Some Money (Score:2)
Re:Save Some Money (Score:2)
Re:Save Some Money (Score:1)
Re:Save Some Money (Score:2)
Re:Save Some Money (Score:1, Informative)
Re:Save Some Money (Score:1)
Re:Save Some Money (Score:1)
Re:MOD DOWN - REFERER LINK SPAMMING ALERT (Score:2)
Re:"Graceful Degradation" = Don't Use It. (Score:2)
Unnecessary != not useful. Possibly buggy is irrelevent so long as you test properly.
Does it take an Einstein to see which is the lowest-cost, lowest-bandwidth, most reliable solution?
Does it take an Einstein to realise that it depends on what you are doing?
Example: If you have something like Hotmail's signup page, you can save bandwidth by using XMLHttpRequest, because you'll get a hell of a lot of people constantly going back and forth on the registration pages trying to get a username that isn't
Re:"Graceful Degradation" = Don't Use It. (Score:2)
The sign up app could also do it in less than 1K per request if it asked for the user name first, by itself, on a page without a lot of other crap on it.
No, it couldn't. A typical HTTP request/response without an entity body is around 1K. That's before you've even begun to send any HTML.
An XMLHttpRequest approach, on the other hand, can signal when a username is already taken with a 409 response, so there isn't any need for an entity body at all.
So unless you've found some magical way of sending