Slashdot Mirror
DHTML Utopia
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?
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.
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.
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.
Sure. I'll just click through your redirect.
Blow me.
Sure, so you can get referral bucks for it? Whatever. Interested parties can get it from this untracked link.
Digital Sailor
Or HERE without this guy's referer code included.
stupid Web tricks of the late 90s that allowed animated unicorns to follow your cursor
If my boss reads Slashdot I think I know what I'll be asked to add to the corporate website tomorrow morning..
http://twitter.com/onion2k
For your reference, this is how "Ajax" got started. I'd say about 75% of the article is useless, but about 25% is actually useful. The main value of the article can be summed up in two words: Mi>eye candy. Jesse James Garrett is good with graphics.
Ajax: A New Approach to Web Applications
How to Download YouTube Videos
The challenge with Ajax, and complex DHTML is that a slight error produces big problems. Its a shame that the book doesn't look at the tooling approaches for instance the Ajax plug-in that Sun have released (via Open Source). DHTML and these active elements can be great, but as a practice I'd be more inclined to have a few people invest time in developing components that the majority of people can use, rather than having lots of people trying to understand the complexities, and buggering it up.
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.
An Eye for an Eye will make the whole world blind - Gandhi
Heaven forbid somebody actually makes a few bucks besides amazon!!! Our whole communist happy world is crashing down!!! What a fucktard.
Copy'n'pasted the summary instead of the title, didn't you?
i have a low opinion of most slashdot book reviews (and the books they review), but this [book|review] sound good.
Do you even lift?
These aren't the 'roids you're looking for.
Only in the past few years has client-side web scripting come out of its 'kiddie' version to demonstrate some really cool hacks (many google examples come to mind) which- coupled with CSS- have changed how we interact with web sites and how they are built. Standards-compliance and strict separation of content and presentation makes CSS+'AJAX' seem like a leap forward in technology when it is actually just a prudent and smart use of old technology. It is a matured technology and with the latest news of IE7 coming closer to compliance, things will only get better. Now if only we could get those kids at home building their first web pages with MS Frontpage to learn...
- click on the "Add to Cart" button
- AJAX adds the product to the card without refreshing the page.
It seems to me that AJAX works worderfully in limited cases that gets rid of the annoying browser refresh problem.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.
Newsfollow.com
Ruby on Rails is really sweet for that AJAX stuff.
threadeds blog
Google paths are case sensitive, so the link should be: Google Suggest.
Suck my balls, douche caboose.
do NOT click the parent's link
he will benefit from this blatant attempt at spamming. he is no better than other spammers like Roland Piquepaille.
Bookpool has this book for $24.95 with no club to join. Bn.com has it for $39.95 (save $5 if you're a club member).
GOBACK.
I don't see why people hate giving others referals. I mean, when people get referal bucks it only costs Amazon.com money--why is everyone on the lookout to save Amazon a few dollars? It's not like it hurts you to help out someone in this case.
No, heaven forbid that guy makes a few bucks from people not intending to donate to his beer-and-porn fund.
--grendel drago
Laws do not persuade just because they threaten. --Seneca
Why is HTML 4.01 better than XHTML?
I've abandoned my search for truth; now I'm just looking for some useful delusions.
anyone got an ebook link?
Because it's a referral disguised as a legitimate post. It's not entirely honest.
94% of Repubs and 21% of Dems voted to renew the Patriot Act
a slight error produces big problems.
I think that's true of just about any language (programming or human) or system.
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.
Since when did operating systems become a religion?
the introduction has a lucid and compelling argument for using HTML 4.01 rather than XHTML as the markup language of choice
Bye !
(Phew, one less long article to read).
pmc258 did neither and is nothing more than a spamming leech. Please mod all his posts -1.
Two years ago, the "Valid XHTML" button was leet as all hell. Now that everyone and their grandma's pantyhose produces valid XHTML (well, mostly (cough)), it's not cool. Since XHTML 2.0 isn't supported anywhere, people had no choice but to declare HTML 4.0 to be the new leetness.
/>
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.
<weblog title=dar weblog! <!-- notice we don't need closing tags!
<stylesheet whereisit="my.leetass.stylesheet" "title'=90k of CSS that somehow convinces me i'm saving bandwidth'/
<post>
<microfont>
Dude, Ruby on AJAX is teh fuckin <a with="annoying tooltip thing>ROOL!
</post>
</post></microfont>
<list of my equally retarded friends
<creative commons license, because that's really going to hold water when someone rips off your stupid weblog></darweblog!<powered by blogzor! >
... stupid Web tricks of the late 90s that allowed animated unicorns to follow your cursor or silly Powerpoint-like transitions between Web pages.
Wow! I been running my website since 1998 and I never came across a web book with stupid web tricks like that. Did I missed something?
Since every page must be coded as if JavaScript/DHTML were not used then which should we choose:
Does it take an Einstein to see which is the lowest-cost, lowest-bandwidth, most reliable solution?
This is an application of Occam's Razor: use only what is necessary and avoid unnecessary complication.
How do you say that a message that informs ppl of a place to get the book for a cheaper price is "disguised as a legitimate post"? if the link went to goatse, that would be one thing, but it IS a legitimate post.
http://www.amazon.com/exec/obidos/tg/detail/-/0957 921896/qid=1122933343/sr=8-1/ref=pd_bbs_sbs_1/104- 7416645-5407105?v=glance&s=books&n=507846 has it for $26 with free shipping (bookpool makes you buy $40 to get free shipping).
Since when did operating systems become a religion?
http://books.slashdot.org/comments.pl?sid=152995&c id=12866355
c id=13160686
o ld=1&commentsort=0&tid=6&tid=10&mode=thread&cid=13 036859
http://books.slashdot.org/comments.pl?sid=156981&
http://slashdot.org/comments.pl?sid=155216&thresh
http://slashdot.org/~pmc255
http://slashdot.org/~pmc257
Granted, the reach is good and for some tasks there's nothing better than web UI, but as soon as you find yourself in need of building something more than just a bunch of web pages with links it all turns into mind-boggligly weir hackery. You start using javascript for layout. You need to manage state. The most trivial UI things become a fucking mess of JS and CSS "hacks", etc., etc. It's also a pain to turn all this crap into components for future reuse, so chances are next time you do something similar you'll have to reinvent the wheel.
The web was originally invented for publishing hyperlinked documents. It's nice to see it come this far, but web as it is is not designed for writing _applications_.
As far as I'm concerned XAML and XUL are the way of the future. Do as much as you can on the client, communicate only what you need to the server, don't re-render everything every time the user needs to change something, concentrate rendering on the client as well.
Remember these simple mantras if you plan on doing a lot of web development in the coming years.
I haven't read the book myself, but well done on a coherent review that covers the resurgence of unobtrusive scripting. The author is quite well respected in the community, and I can only hope books like these begin to replace the "omg dhtml netscape 4!!11one" fare usually found on shelves.
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 browsers. GMail, for instance, had to write another whole separate version using plain HTML for legacy useragents; this seems a little beyond the "progressive enhancement" ideals in which JavaScript adds to, rather than replaces, essential page functionality. I'm putting together my own LGPL'd AJAX library that operates via plain HTML links and forms (and yes, those IFRAME hacks you speak of are really hard to get right!). So in theory it should degrade well.
And what the heck, while I'm self promoting, here's my free event manager script that works around IE memory leaks, as well as making the whole cross-browser-event-handling stuff easier (which is still the main annoyance when writing cross-browser code -- hurry up and implement DOM Events, MS!). Hope any other JS coders here find it useful.
<!-- DHTML / JavaScript menu, popup tooltip, Ajax scripts -->
Parent tries to boost his/hers website in Google pagerank. Also, comments offtopic.
Can anyone tell me why Microsoft's "XML Data Islands" didn't take off in the mainstream given that IE has had a 90% browser share? For external XML they are simple and neat and don't require any javascript whatsoever for basic fetch-and-display use (but you can enhance functionality using javascript).
Here's a demo (use IE5 or later). I figure they must be in use somewhere because there's even a Mozilla article on getting them working in Mozilla.
Alas not. You have no idea whether the book is being touted purely to make money for the poster. I.e. there's a huge conflict of interests.
Anyone have a link the of the Torrent?
The publisher of this book, SitePoint.com, is offering a free DHTML Quick Reference Poster for ordering directly through their Website ($39.95 - just like BN.com). They also sell the poster seperately for $9.95. It looks useful and very cool.
Websites are now using these instead of regular popups to get by the popup blockers.
Animated Unicorns.
For an example of drag and drop in use, check out Panic's website
So HTML 4.01 is better than XHTML because IE is broken? Isn't that like saying a Kia is better than a Ferrari because there is a 55mph speed limit?
I've abandoned my search for truth; now I'm just looking for some useful delusions.
Try this small DHTML thingy we made :-)
o /pure_javascript_demo_by_IKU.zip
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.
Although applets require Java to be installed on the machine ( and the java plugin integrated with the browser ), it possible to do without XMLHttpRequest.
Actually, it was already 5 years ago. At least with netscape browsers.
All you need is to call your applet from javascript, get the applet to talk to the server and you will have your server query without any page refreshes.
As an added bonus, you can TEST the applet as part of the server solution. Can you do that with XMLHttpRequest?
I'm so far ahead of this guy it hurts...
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!
and your work. I'd already visited your site some (not so long) time ago. Very good, nice and useful stuff in there.
Keep up the good work.
Regards,
Articulos para gente geek: Poleras, linux, libros y mas
Just remember to give the W3C a great big hug for all their hard work, despite how some around here treat them.
Whenever I see books like this, I always wonder why people do not use the dynlayer api. DynLayer Api at SourceForge This has been around for quite sometime. Handles drags, moves, events, layers, z index, etc. Everything. True, it is now a bit big, but do like I do and remove what you do not need and away you go. You can AJAX as a separate piece.
- Creativity is more important than knowledge. - Albert Einstein
Instead of modding this fool up, down or sideways, complain to Amazon's Associates program directly. Include his referrer tag and they will almost certainly revoke his affiliate status because of unacceptable spamming in violation of Amazon's Affiliate agreement. His Amazon affiliate ID is kaleidojewel-20 and associates@amazon.com is the place to email your complaints to. If we nip this in the bud, there'll be no more incentive for such spam. Please be polite when emailing Amazon - this *is* against their policies, they just need it to be brought to their attention.
HTH
Ciao
Zak
solution part 1
solution part 2
[insert witty comment here]
What?! It costs money?! But information wants to be free!
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.
"Our interests are to see if we can't scale it up to something more exciting," he said.
How is this against their policies thought? I went an looked up the "Amazon Operating Agreement" or whatever, and it doesn't seem to mention anything in specific. There is, however, a very generic clause about how all associates should abide by the US laws regarding spam (ie. CAN-SPAM Act?). I don't know how extensive these laws are, and whether or not they cover one comment placed unintrusively in a Slashdot discussion.
Funny, this book arrived today at my house. I was hoping the section on AJAX would be more extensive, but it's relatively slim.
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.
Are you retarded? This guy is spamming Slashdot left and right:
c id=13217853
http://books.slashdot.org/comments.pl?sid=157754&
Jesus. Fucking spammer supporting asshole. Fucktards like you are the reason why my inbox is full of utter garbage.
If '404 not found' is graceful degradation I don't want to see ungraceful degradation.
I love AJAX. It's fast for development and powerfull. JS+XUL=POWER ;-)
Well, I've got to get back to work. When I stop rowing, the slave ship just goes in circles.
... 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.
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
The one part that I don't get about the "new Javascript" philosophy that has been going around is, why people are so obsessed with keeping the scripts optional.
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 seems to add a lot of time (read: money) for little benefit. Too many bucks for too little bang.
Also, you can't point at CSS and say that just like good CSS is unobtrusive, so is good scripting. Apples to orange. CSS is about presentation. And unless you're a marketing person, presentation IS optional. A colorful, three-column positioned blog done with CSS that degrades to plain black on white text laid out from top to bottom, is a good thing. Or at least it's fun to develop and then brag about how well it degrades. But scripting is NOT presentation, or at least it is not JUST presentation. If what you are developing is not a "web page" but a "web application", then scripting is part of what the application does.
Finally, don't anybody trot out the line about companies that forbid their employees from running browsers with JavaScript enabled. I haven't seriously known of a policy like that since about 1998. You also hear the same thing about cookies, and that's BS as well.
I am not trolling I actually don't get it.
where there's fish, there's cats
Sure the *web* was originally designed around the idea of hyperlinking documents.
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 than it is for many operating systems.
The security side doesn't need much explanation, browsers though insecure are still better than installing random executables.
Should a user have to download and install a program just to get a rich ecommerce experience?
XAML and XUL are just another (albeit, better) way to do this. Apps to use it (Moz) just aren't ubiquitous (yet). However, generally, XUL apps are just as Javascript heavy as a DHTML app. Alot of the ideas behind these DHTML apps are the same as you propose for XUL, "Do as much as you can on the client, communicate only what you need to the server, don't re-render everything every time the user needs to change something, concentrate rendering on the client as well."
The big downer will be when people decide that sites/apps should only be usable by browsers with these capabilities. Then again, thats been happening for awhile.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
1. You need to maintain state (and re-parse it on every request, or execute dozens of SQL queries to fetch it from the DB).
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. You can't! I could come up with three dozen more examples of what you should be able and can not do. I kind of can even understand Microsoft who said CSS2 is a fucked up standard and it's better to wait for CSS3.
The add method on a select element exists in IE 6 as well as Firefox. However, in order to add an option element to the end of the select element's list, you need to do this in IE:
And this in Firefox:
References:
MSDN Reference
DOM Reference
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!
Reason is the Path to God - Anon
but he isn't touting the book merely giving you a cheaper source than the article gives.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register