JavaScript : The Definitive Guide, 4th Edition 208
| JavaScript : The Definitive Guide, 4th Edition | |
| author | David Flanagan |
| pages | 916 |
| publisher | O'Reilly |
| rating | 9 |
| reviewer | Brian Donovan |
| ISBN | 0596000480 |
| summary | The latest edition of JavaScript : The Definitive Guide brings the popular reference up to date with extensive coverage of W3C DOM Level 1 and 2 and a much-improved and expanded set of appendices. |
The Book in a Nutshell
Although much of the core of the language, addressed in Part I, has changed relatively little since JS:TDG3, Flanagan has added coverage of new issues that have emerged in the past several years, like the discussion of ASCII, Latin-1, and 16-bit Unicode in the beginning of Chapter 2 (ECMA-262 Edition 1, the spec that defined ECMAScript, included Unicode support for il8n purposes, so ECMAScript compliance requires Unicode support), and pruned away quite a bit of material related to NS 4.x-proprietary features, like the explanation of import and export (previously found in Chapter 6), that are naturally of increasingly less interest to developers as that line of browsers recedes into history. Much of Part II, which considers client-side JavaScript and DOM in all its glory, is entirely new or has been completely re-written. Where the chapter on the Document Object model in the 3rd edition only covered the "Level 0" DOM (the objects, properties, and methods first exposed by the 4.0 browsers), JS:TDG4 tackles the Level 0 DOM and the W3C DOM Recommendations through level 1 Core and HTML and touches on some DOM Level 2 topics, including the Range and Traversal APIs. "Cascading Style Sheets and Dynamic HTML" and "Events and Event Handling" are two other chapters in the Client-Side JavaScript section that have really come into their own in this edition.
The large (more than 300 pages), but somewhat muddled "JavaScript Reference" in the 3rd edition (it had commingled the objects, properties, and methods included in the core of the JavaScript language with those of the Level 0 DOM) has been split into 4 discrete appendices ("Core JavaScript Reference", "Client-Side JavaScript Reference", "W3C DOM Reference", and "Class, Property, Method, and Event Handler Index") that, taken together, comprise more than 400 more pages of information. NS 4.x fans can take comfort from the fact that, while much NS 4.x-specific information has been culled from the body of the text, Netscape 4.x still shows up in some screen captures (along with Microsoft Internet Explorer and Netscape 6).
What was Great
Exception handling (using throw and try/catch/finally) is covered in greater detail. In Chapter 15, "Forms and Form Elements", JavaScript interactions with buttons, toggle buttons (checkbox and radio elements), text fields, hidden elements, and fieldset elements are addressed individually in new sections not present in the corresponding chapter in JS:TDG3 and the section on select and option elements goes into more detail than in the previous edition. Throughout the book, improvements have been made to figures and tables - like the addition of the "Supported by" column in Table 19-1 : "Event handlers and the HTML elements that support them", which now helpfully lists the elements for which the event handlers can be triggered after identifiers for the versions of Netscape and Internet Explorer in which the behavior is observed. Finally, the book as a whole is significantly more readable. The type used for the text of the code examples and tables was too "light" in the 3rd edition (at least in my copy), and I was glad to see that it's a bit heavier in the 4th.
What was Not so Great
I nearly came up empty-handed in my search for defects in this book, but noticed that, in tables 11-1 and 11-3, "Automatic data type conversions" and "Data type manipulation in JavaScript" respectively, information relating to the treatment of arrays and functions present in the corresponding tables in the 3rd edition has been removed. That's really my only gripe. Some might wish that Flanagan had included more compatibility information, but, realistically, the task of fully documenting the intricacies of what's supported by which browser (or, in the case of Win MSIE, which JScript dll is installed) could probably fill a separate book all of its own. Moreover, Chapter 20 ("Compatibility Techniques"), may be brief at only 11 pages, but it does a good job of tackling best practices in dealing with JavaScript and DOM cross-browser compatibility challenges.
To Buy or Not to Buy
If you're in the market for a good JavaScript (or JavaScript+DOM) book, then JavaScript : The Definitive Guide should undoubtedly be your first choice. Although my 3rd edition was so tattered from long use that I really had no choice but to upgrade, even owners of the 3rd edition who've managed to keep their copies in near-mint condition will probably still want to get their hands on the 4th edition if they haven't already done so - for the meatier and updated reference appendices if for no other reason.
Table of Contents
Preface
- Chapter 1. Introduction to JavaScript
Part I : Core JavaScript
- Chapter 2. Lexical Structure
- Chapter 3. Data Types and Values
- Chapter 4. Variables
- Chapter 5. Expressions and Operators
- Chapter 6. Statements
- Chapter 7. Functions
- Chapter 8. Objects
- Chapter 9. Arrays
- Chapter 10. Pattern Matching with Regular Expressions
- Chapter 11. Further Topics in JavaScript
Part II : Client-Side JavaScript
- Chapter 12. JavaScript in Web Browsers
- Chapter 13. Windows and Frames
- Chapter 14. The Document Object
- Chapter 15. Forms and Form Elements
- Chapter 16. Scripting Cookies
- Chapter 17. The Document Object Model
- Chapter 18. Cascading Style Sheets and Dynamic HTML
- Chapter 19. Events and Event Handling
- Chapter 20. Compatibility Techniques
- Chapter 21. JavaScript Security
- Chapter 22. Using Java with JavaScript
Part III : Core JavaScript Reference
Part IV : Client-Side JavaScript Reference
Part V : W3C DOM Reference
Part VI : Class, Property, Method, and Event Handler Index
Index
You can purchase JavaScript: The Definitive Guide from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Chapter 5 (Score:5, Funny)
Re:Chapter 5 (Score:1, Funny)
Re:Chapter 5 (Score:2, Funny)
boolean detectParents()
usage:
if(detectParents())
displayPorn();
Re:Chapter 5 (Score:2)
I got a self-minimizing, onUnLoad() self-re-opening ad. I had to end task on Iexplore b/c End Task tries to shut down the task in a friendly manner first, which triggers the onUnLoad().
Don't know what it was, or how they expected me to see it.
Time to go home... (Score:1)
It's friday afternoon, it's 16:30 over here, I'm at work, it has been a busy day, and I was convinced it read 'the masturbation..'. I think I'll call it a day and go home now.
Great. (Score:2)
Install Mozilla (Score:5, Informative)
Edit -> Preferences -> Advanced -> Scripts and Plugins -> Open Unrequested Windows. Uncheck. Done.
Problem solved.
Re:Install Mozilla (Score:1)
Re:Install Mozilla (Score:2, Informative)
Re:Install Mozilla (Score:2)
I actually did try it and found it blocked a huge amount of content I did want and offered no flexible "bypass" - even a key or something so I could look at a particular page.
This is really an example of a feature added with good intention but useless implementation. I use Mozilla and a 3rd part (free) pop-up stopper/proxy server.
Re:Install Mozilla (Score:2)
Re: (Score:2)
Re:Install Mozilla (Score:2)
This is the old Mozilla behavior (pre-0.96). Since then it has evolved into not opening a ne window unless the call was made within a certain amoutn of milliseconds of a mouse click. This is pretty much IMPOSSIBLE to fake out.
If you haven't used mozilla since 0.96 you don't know what you're missing, it has improved alot. I never use IE here or at work anymore. Download it then go to themes.mozdev.org and get some cool skins.
Re:Great. (Score:2, Informative)
Any decent browser nowadays can block popups while keeping Javascript enabled. Go get Mozilla [mozilla.org], Galeon [sf.net], Opera [opera.com], Konqueror [kde.org]... the list goes on and on.
In short: Don't use IE, and you won't get popups. Your browsing experience will also be faster and more intuitive.
Re:Great. (Score:2)
Well, like so many other tools the evil is in the intent of the wielder. I've been finding that javascript has become absolutely essential as web users have come to expect the same level of slickness they see on their desktops from their web browser. A case in point is the MyLibrary portal I implemented at the U. I expected the user comments to ask for more services and better grouping of information, y'know, the type of thing librarians might be concerned with. Instead almost all of the suggestions for changes in the next version were about the interface. Adding it all up, it was clear that the users were expecting the stuff in their web browser to behave like their main computer interface in terms of windowing, menu selection, being able to minimize things and so on. I don't know if I could have implemented their requests without Javascript
Re:Great. (Score:2)
The reason I say this is not just general philosophic argument, but the fact that when creating actual web apps (and I don't mean hype-oriented buzzword meaning but 'real' applications done using thin client, ie browser) ability to open a new small window is really really necessary and useful. These are useful for displaying on-line help, opening up save/load windows (custom ones that will allow user to save data from main form window to/from a file in server side, but first browsing using GUI on popup window), opening up a config window etc. If you can't see the point, try to think if traditional apps were not allowed to open new windows (or tabs for Mozilla; different implementation, same idea).
It should be possible to have features in browser to conditionally enable/disable popup ability on case-by-case basis... but no one wants to be ok'ing "Is it ok to open popup" dialogs. :-)
One feature that seems pretty useful is to just disable javascript's ability to open a popup from 'onUnload' event, ie. pages can not bombard you with popups when you leave them.
Re:Great. (Score:2)
Do you have write access to your hard drive? ANYWHERE? to save anything? Then you can install Mozilla. It doesn't need access to any specific directory or your registry or anything, unlike other gay software. Download the zip file, unzip. Done. Install the IE theme from themes.mozdev.org so you don't get caught red-handed.
Timing (Score:1)
Use Addall instead... (Score:3, Informative)
Javascript not dead (Score:1)
Heck, Macromedia uses JavaScript as the programming language for FireWorks and DreamWeaver customization. I think the next gimp release will allow you to use Javascript for scripting (like you can do with Perl and Scheme). Too bad source forge searching is down right now, or I'd find the link for that project....
Re:Javascript not dead (Score:4, Informative)
Plus, I know an increasingly large number of ASP developers who use Jscript (microsoft's Javascript, they just can't use the name) as the scripting language for the Server-Side ASP code (rather than the VBScript mose use). Why? It just makes more sense. It's annoying to "switch mental gears" when going from the client-side code blocks in Javascript and the server-side VBScript blocks. Also, many are in the boat we're in where we do some Java stuff as well. Syntax is fairly consistent between Java and JavaScript.
Re:Javascript not dead (Score:2)
Re:Javascript not dead (Score:2)
Even Microsoft's own web-based outsourcing support tools use JavaScript almost exclusively. They are ugly beasts, written entirely in DHTML, with JavaScript controlled XML server communication, with <span> tags using onClick() and CSS to do the underline hover, instead of links...
Surprise! Even their websites are bloatware! Of course, that's no surprise if you've ever looked at MS Word/Excel MSHTML.
O'Reilly quality has gone down (Score:2)
I miss the old days where I would buy O'Reilly books - no matter the topic - almost without cracking open the cover because I knew I could count on an authoritative, well-written-and-edited book that almost certainly was one of the best books on its topic. Now, it seems like O'Reilly is milking their goodwill and pumping out bushels of substandard quality books. I know, because I've bought a bunch of them.
Now, there doubtless were substantial revisions and additions to bring this particular book up to the 4th edition, but I just can't bring myself to buy an updated copy of what was at the time perhaps the worst O'Reilly book that WASN'T "CGI Programming on the World Wide Web" by Shishir Gundavaram.
Fool me once, shame on you
Fool me twice, shame on me
Can you give some examples? (Score:3, Informative)
So - what titles would you warn against?
Re:Can you give some examples? (Score:2)
So - what titles would you warn against?
One I with which I was particularly underwhelmed [slashdot.org] was their book on PostgreSQL. Also, their guide on Apache doesn't seem to cover anything that isn't already covered in the Apache documentation. Not to mention the fact it only covers up to Apache 1.3.3!
To be fair though, I'm happy with other O'Reilly books. There is of course the Camel book, plus their book on Web Graphics using Postscript and GNU Software. Also, the book Cascading Style Sheets: the Definative Guide is also of high quality.
Re:Can you give some examples? (Score:3, Informative)
Another disturbing trend is that new books don't contain information that is as up-to-date as before. An obvious example is CSS Pocket Reference [oreilly.com]. Even though it was published last year, it doesn't cover any of CSS2. For some odd reason, the book was published right before IE6 was released, and so doesn't have any information about what will become the most popular browser in the world this year. And don't expect a corrected printing any time soon!
It used to be the case that you could count an O'Reilly books having the most accurate and up-to-date information. Nowadays, that isn't true any more.
Re:Can you give some examples? (Score:2)
Meanwhile, as your links show, you can always check the book's web page on the O'Reilly site for errata. Just print that page out and keep it with the book (or even go through and make the corrections by hand). Beats paying for a new edition.
Re:Can you give some examples? (Score:2)
Re:Can you give some examples? (Score:2)
The only O'Reilly book I own that I can say sucks is the old MySQL one [oreilly.com]. I own dozens of O'Reilly titles and that is the only one I ever regretted purchasing.
The only publishers I trust are O'Reilly, Addison Wesley and the in-house publishers (Oracle Press, Sun Press, Microsoft Press). Anything else I typically wait for someone to really reccomend the book before I'll buy it.
Re:O'Reilly quality has gone down (Score:2)
If you need a JavaScript reference, you are best served by looking for the best available book rather than making such decisions based on idealistic dogmatic opinions of publishers.
Yes, O'reilly isn't what it used to be, but what does that have to do with purchasing a book?
Strengths of Javascript. (Score:5, Interesting)
Unfortunately, when most people hear the word JavaScript they immediately think of how annoying window.open() is. It is a shame, really, as a lot of interesting things can be done using JavaScript. Especially when combined with the DOM and all the options that opens up.
My question, then, is simple. How many people have noticed that true knowledge in JavaScript is severely lacking in many people who do web developement? I've met lots of people who claim to know JavaScript well, but they can barely write the examples provided in most books. I think that for a web developer, knowledge in client side scripting should be moved up on the priority notches. Am I alone in this?
Re:Strengths of Javascript. (Score:3, Interesting)
Re:Strengths of Javascript. (Score:2)
As the developer of database-driven intranet applications, I was frequently grateful for JavaScript. When three managers would finally agree on a implementation which was practically impossible to create, I would rely on JavaScript to make the impossible happen.
JavaScript is extremely versatile. It is also very powerful. However, it is also very easy to abuse. If you've ever visited a site where layers of transparent GIFs floated around following your cursor, you probably understand. I have had to troubleshoot a fair share of bad JavaScript that others wrote/copied (subducted layers of size-and-color-changing fonts making a colorful expanding flashing title was chewing 97% processor time, for instance) and have taken the Aramon [cavedog.com] stance on JavaScript.
Stone and steel are at Aramon's side, and good king Elsin forsakes magic for spear and hammer.
Re:Strengths of Javascript. (Score:2)
Of course, you should still have the same check on the server side as well, since you can't guarantee that the client has JavaScript enabled (or didn't just hack a local copy of your form themselves).
-Karl
Re:Strengths of Javascript. (Score:3, Informative)
Re:Strengths of Javascript. (Score:3, Funny)
Wait a minute ... why doesn't your site work in my browser?
What's that you say? My site doesn't work in your browser either?
How very strange.
Moderation totals: +1 funny, -1 gratuitously sarcastic.
Re:Strengths of Javascript. (Score:2)
Also, it is true I didn't say it. Which is why I said now. I've had this conversation many times on Slashdot. These guys pay the bill, they have the right. Support wise, it's a nightmare to support multiple clients and they don't want it.
Re:Strengths of Javascript. (Score:3, Interesting)
Seriously. I dont' go to some sites because it requires a seperate window to open automagically, while I have that setting in mozilla off. It's not a matter of protest -- it's a matter of preference. I don't like it, and got annoyed turning it back on for the site in general. So.. I've stopped going there.
The bigger problem, is it is hard to worry about it client side. If I turn off JS, bam, your site becomes broken. Depending on the use of JS, it can either be a security issue, to db integrety (data validation) to site navigation that becomes broken.
Re:Strengths of Javascript. (Score:2)
JS has been crucial for leveling the resources between client, web- and database servers.
People seem stuck in the familiar rut, and looking at a page that has four languages (HTML, JS, VBScript, SQL) decorating it seems to scare the intellectually limp in the crowd.
The application learning curve is steeper, but it's a "feature" to know where the code will execute simply based on the default language settings that are common through the application.
This is all stated from the relative comfort of an internal database application. Heart goes out to the commercial types forced to jump through their butts with their hair on fire aiming for compatibility; we get to say "IE or ELSE".
Re:Strengths of Javascript. (Score:3, Insightful)
Cheers,
Re:Strengths of Javascript. (Score:2)
From a "consumer" perspective, there are way too many sites out there that go to the server to update the page after an action. So much can be done with really very simple CSS and DOM manipulation.
I mean, it's easier code to write, it'll work with very little platform-specific tweaking, and it's a better experience for the consumer since it's faster to download the code and update the page. Why isn't it being done?
Re:Strengths of Javascript. (Score:2)
Artists and page designers consider javascript the coder's job, because, well, it has logic branching, variables and function calls (to list off a subset of the functionality.)
Coders consider it the web designer or artist's job, as it often lays out asthetic views of the work.
Managers don't care, they want to see all their functionality implemented in flash. :-)
Seriously though, I'm one of the few staunch software developers who picked up web programming (as opposed to web designers who learned a bit of php&javascript) where I work who spent the time learning Javascript, coincidentally from the 2nd edition of this book.
The result? Almost every piece of web software I've written in my career could have had a once-over interface improvement by using something out of it. I appreciate Javascript.
One of the unsung uses of JS that I find so helpful is for the administration section of sites that I so often have to code for clients. Most of the time, the client will ask for some highly complicated features after you're already done programming something to spec. While it is fully within my right to hand them an updated schedule and cost for the changes, some of the time I can simply hack them in with JS. Sure, I can't rely on most users to have Javascript, but I can tell a few admins that they're going to need it.
Let's not forget that Javascript is not tied to the web either. The DOM is velcro'd to the language, not bolted.
I personally wish more people would use javascript with their forms, even if it is just to put an onLoad in the BODY tag, with a focus edict on the first entry in the first form.
Re:Strengths of Javascript. (Score:3, Insightful)
The only problem with JavaScript is as you cite:
I've enjoyed using JavaScript for almost as long as I've been using HTML (4/5 years), and believe it can genuinely help to reduce server load (think of all those validation scripts), yet JavaScript is steadily becoming less applicable due to the ability to disable it in the client.
A lot of ordinary web users, in an effort to block pop-ups, have disabled JavaScript in their browsers, and all other applications which could easily make use of this technology suffer as a result. Personally, I couldn't blame them for this, as I find pop-ups as irritating as the next person.
Until ordinary web-users come to trust web sites not to thrust adverts down their throats using pop-ups, pop-unders or whatever, then this valuable technology will remain unusable on the vast proportion of (mainstream) web sites.
Of course, the odds of marketing-types not pressing developers to use any technology in an immoral way are extremely remote.
You Are Not Alone (Score:2)
Nobody should be taught or allowed to use a Wysiwyg editor until they can build and work without it.
Other folks who come to me for fixes to thier Frontpage and Dreamweaver problems drive me absolutely nuts.
Ok, you've got wizards and plug-ins. What do you do when they don't work, or when your stuff doesn't display like you need it to? You harass people like me to tweak what you should have known before you ever were allowed to be paid to do web work.
End of rant... Keep coming to me, I complain, but I do enjoy the attention.
Re:Strengths of Javascript. (Score:3, Interesting)
Also, most people don't seem to realize that question between server/client side validation (or functionality) is not all-or-nothing. They are pretty much complementary. Client-side is really good at making web apps much more responsive and interactive. Server-side is a must for secure stuff; anything on client-side can be manipulated at will.
For example, I do think that it's much better do (parts of) simple syntax / completeness validation on client-side. Instead of having to wait for server to output "You didn't fill 'foo'" page, you could get an alert dialog telling you the same, and:
More complicated checks should be done on server-side (not all data may even be available at client), but for (pre-)validation JS makes things much easier.
my opinion (3rd edition) (Score:5, Informative)
I have seldom had a question about JavaScript for which I could not find the answer in this book. I referred to it so frequently during the development of our system that it is now the most dog-eared book in my collection. I'm going to order the fourth edition simply because this baby is ready for retirement.
If you are learning client-side JavaScript, by all means purchase this book. The first half of the book is a guided introduction to the language and does a wonderful job of explaining the syntax of the language, the underlying object model, and virtually every pertinent feature of the language. The real value, though, is in the reference, which documents every object, method, property and event of standard JavaScript.
Non-conformists who wish to exploit features unique to Internet Explorer will find some reference material here, but the book does try to focus on the "standard" features of the language, which I think is a good thing.
You just can't go wrong with this book.
Great in previous editions (Score:2)
Typecast (Score:1)
JavaScript... (Score:1)
Great book.. (Score:4, Informative)
Re:Great book.. (Score:2)
what I think (Score:2, Insightful)
No joking, Javascript is evil. (Score:3, Interesting)
Variables can be declared or not, line termination is optional, it's supposed to be object-oriented but there's no way to decalare class or methods, some construct are really horrible:
value =selectBox[selectdBox.selectedIndex].value
Scripting language for HTML should be easy,simple and have the right features (who needs the C++ binary operators anyway >>, Any project going to implement different scripting language for mozilla?
Re:No joking, Javascript is evil. (Score:2, Insightful)
Variables can be declared or not, line termination is optional, it's supposed to be object-oriented but there's no way to decalare class or methods, some construct are really horrible:
value =selectBox[selectdBox.selectedIndex].value
then you also don't like perl, i take it, since all your complains apply there, as well.
while you can't declare classes as simply as you can in some other languages, you can use the javascript prototype mechanism to do the same thing; and you certainly can create constructors and methods. evidently, you need to study up on the language a bit more. the book under discussion here would be a good place to start.
JavaScript is a solid language and can be used to interesting and useful things on the web. the fact is, people abuse every language, in one way or another. no user is forced to be lazy and propagate write-only code; it's done all the time in C, C++, perl and probably any other language you would care to name.
mp
Re:No joking, Javascript is evil. (Score:2)
value =selectBox[selectdBox.selectedIndex].value
That's a DOM issue, not a JavaScript issue. And, BTW, that's only necessary in IE. In Netscape, value = selectBox.value works just fine.
Re:No joking, Javascript is evil. (Score:2)
Hmm, I've heard a couple of times that JavaScript actually is quite good very OO language from some quite good programmers.
It's supposed to be object-oriented but there's no way to decalare class or methods.
I could be wrong as I'm not JavaScript programmer but AFAIK you can add methods to object. Yes, you cannot create classes because it doesn't have them! It is called prototype based OOP. You create object, add more methods to it and clone it to get a bunch of objects having simular type. If it doesn't sound like C++ or Java it doesn't mean it is bad.
JS != OO (Score:2)
There is no inheritance at all, it's just copying values from a previous defination.
in JS you can declare Object, then declare Object that 'extends' the first one. All the engine is doing is copying all the values from the first Object to the second. You can't call super.method() because that doesn't exist. If you could call super.method, then there would be inheritance.
Methods are not overloadable and can take any number of parameters. Objects are wacky because the same name can point to both a function and a variable.
var o;
o.callme = function ( a ) { alert ( a ) ; };
o.callme('a');
o.callme = ' a ';
alert( a.callme);
This code is kind confusing, and as such is one reason that I don't like JS, because other people code like this.
So to sum up, JS is a neat language but its 'features' make it hard to create large applications with it.
Alternate titles (Score:4, Funny)
2. Breeding Cookies for Fun and Profit
3. Learn Browser Crashing in 21 Days
4. Fantasy Pretend Programming for Beginners
5. Make Everyone Hate the Web in Five Easy Steps
Oy, I'm getting to be so cynical in my old age.
Note to the humor impared: This is a joke. Don't take it seriously because this is a joke. Don't be offended and flame me because this is a joke. Don't get all huffy and defend java and java script to your last dying finger twitch because this is a joke.
Here it is, the definitive statement on this post: THIS IS A JOKE!
Re:Alternate titles (Score:2, Insightful)
Alternative title #6: How To Build Really Spiffy Web Sites That Will Work Perfectly For You And About Two Other People, Provided They Both Use Exactly The Same Browser, Operating System And Patches As You, in 22 easy chapters
Re:congrats, you're an idiot (Score:2)
Re:congrats, you're an idiot (Score:2)
Good thing for Mozilla (Score:4, Insightful)
"Hey, 1 out of 20 of our potential customers can't use our website!"
And I think that IT should be pitching that same line to the suits.
Anyway, until someone develops intellegent JS filtering that works, I just turn it off.
Re:Good thing for Mozilla (Score:2, Interesting)
There's nothing wrong with building features in, as long as they're supplementary to the browsing experience - anything critical to browsing must be done in HTML. IMHO window.open() should be categorically banned from all browsers - there is no need for popups to open on page load or close, and, if a page needs to be opened in a new window, you can always use <A HREF="whatever" TARGET="_new"> - of course, if the browser doesn't support the TARGET attribute, you get to view the page anyway, just in the same window.
Re:Good thing for Mozilla (Score:2)
a lot of offices that standardized around Netscape 4.x a long long time ago still use it, or have moved to 6.x/7.x now.
theres Opera
there are text-only browsers for the disabled
there are older versions of IE still floating around out there
it just seems crazy to require IE 5.0+ features when NONE of them are required or are even that handy for running e-commerce.
I think HTML should be standard HTML, you should make all your pages so that anyone can access any essential info, services, and features with a simple, standards compliant browser. I understand the desire for a flashy front-end, and for that I would suggest using Macromedia since it's much better and more available than MS exclusives, and by and large has built in bypasses for people who don't use Flash (assuming the web designer is smart enough to use them)
I understand why people use Windows. Hell, I even understand why some people use Outlook. But I don't understand why anyone would write a webpage that won't work on a non-IE platform. That's just stupid.
yeah, I know you were joking. and it was pretty funny, and partly true. I just felt like expanding my thoughts.
Re:Good thing for Mozilla (Score:2)
In a book that will be used by many web developers, having an official expert opinion saying that authors need to be aware of non-IE browsers is a very good thing for alternative browsers in general, and a good thing for Mozilla specifically.
Compatibility Question (Score:2)
I keep hearing second hand information from web developers that Mozilla's javascript implementation "breaks" compatibility, whatever that means.
Re:Compatibility Question (Score:4, Insightful)
Mozilla doesn't support a few DOM access methods that IE does, because they're not in the W3 specs... they use alternative methods that IE also supports, but this leads some people to say that Mozilla's scripting support is 'broken'.
(Tangentially, I was reading on Bugzilla about some performance problems with Mozilla's JavaScript & DHTML, but that was more speed-related than functionality-related, I think.)
Re:Compatibility Question (Score:2, Informative)
For one thing, remember that compatibility is very often not a matter of the JavaScript, but the Document Object Model within the browser that you are trying to manipulate, which implies CSS compatibility. http://www.webreview.com/style/css1/charts/master
And as far as checking differences between browsers, that is simply a matter of checking the version your browser supports against a version of JavaScript (while I have heard that there are different implementations of different versions...but that's an experience thing I think). So you could go to http://www.gemal.dk/browserspy/js.html, check your JS browser support, and then when you reference a book on JavaScript, just take note of what version they are referring to.
Danny Goodman's books used to really spend a ton of time on compatibility (http://search.barnesandnoble.com/booksearch/isbn
While this response does not give you a chart, I have found, both programming in it and teaching it, that just being aware of supported versions and maybe not always implementing the newest features (which are often just shortcuts to do things one can already program) in JavaScript should keep one out of too much trouble. But man, that CSS stuff is what kills.
Hope this helps.
Re:Compatibility Question (Score:2, Interesting)
I find Mozilla's javascript implementation to be better than explorer's actually. The behavior is more consistent and well defined. The event bubbling (which most developers won't use consciously) is fully up to spec, whereas ie support is still a bit flaky in some of those things.
Personally I prefer Mozilla, but it is more a matter of good png support, tabbed browsing and other features ie is still behind on. Also, I HATE the new (as of ie 6 I think) image management "features" in Internet Explorer (the annoying toolbar that shows up when you mouse over images, and automatically resizes jpegs to fit the screen) yes, it can be turned off, but it annoys the hell out of me when the browser modifies in any non standard way the look of a page without asking.
--
Re:Compatibility Question (Score:2)
I believe in taking a slightly different tact - sniff for the function you want to use when you want to use it. Why rely on the assumption that only IE supports document.all (or something similar)?
I find Mozilla's javascript implementation to be better than explorer's actually. The behavior is more consistent and well defined. The event bubbling (which most developers won't use consciously) is fully up to spec, whereas ie support is still a bit flaky in some of those things.
Hear, hear! Mozilla is wonderful for JavaScript. True, it's often more rigid than IE (which lets you get away with a lot of bad coding practices), but I find that if a script works in Mozilla, it's much more likely to work properly in other browsers than the other way around. The debugging tools are also very nice. Being able to quickly test a refex or a short snippet of code in the JavaScript console saves a lot of time. The error reporting is pretty god too (IE has the most utterly useless JavaScript error messages).
Also, I HATE the new (as of ie 6 I think) image management "features" in Internet Explorer (the annoying toolbar that shows up when you mouse over images, and automatically resizes jpegs to fit the screen) yes, it can be turned off, but it annoys the hell out of me when the browser modifies in any non standard way the look of a page without asking.
No kidding. Ugh. It's quite non-intuitive as well; it starts off drawing the image in its native dimensions while it loads, but all of the sudden when it finishes it shrinks down. Then I have to wave the mouse over the image for 5 seconds until I can finally get that little 'restore size' icon to pop up.
Forget popups (Score:3, Interesting)
LEXX
Re:Forget popups (Score:2)
And don't give me any guff about cross-platform compatibility. A), javascript doesn't have it, and B) most js-heavy systems are intranet-based and targeted at a set browser+platform combination anyway. And even ignoring A and B, Java would be the better choice.
client-server, presentation-application, it's not rocket science.
Re:Forget popups (Score:2)
LEXX
Re:Forget popups (Score:2)
Or, you could normalize the data, so you don't have to parse a string at all. Much of the unnecessary JavaScript complexity in many websites stems from poor design of the data fields. Unfortunately, poor data field choices, in turn, stem from poor database designs, so a lot of JavaScript can actually point out a fundamentally screwed-up application.
If you insist on using JavaScript, it becomes trivial to check that the month field is between 0 and 13, for example, when everything is split up properly.
Database design--as much now as twenty years ago--is still the most important thing to get right (in an application that uses a database, that is).
Re:Forget popups (Score:2)
I just got done writing the exact app I mentioned (credit app taking) using Java servlets with Velocity and client-side Javascript. Exactly as you described and no it isn't rocket science. The app is used by over 3000 car dealerships nationwide. We ain't gonna support a desktop app for all those people, no freaking way. And no it isn't targetted at one single browser/platform. And it works beautifully, taking over 30000 apps a month. And it uses Javascript for preliminary client-side validation of data so as to reduce traffic for us and lag for the user. Could have _made_ it work without JS, but that would have been retarded.
Now tell us about the large-scale project have you successfully completed and how was it structured.
LEXX
Re:Forget popups (Score:2)
Now that I think about it, I can't think of a reason to use JavaScript on something like a credit application. It's just data entry, and the credit check either needs to be done on the server or by a person, anyway. (Also, see my other reply about normalizing data to avoid JavaScript altogther).
A credit application can be done well with pure HTML and a CGI program or Servlet for processing.
Learn the tricks the Pros use (Score:3, Funny)
Once you've mastered that, you can go on to advanced topics like a "browser detection script", that refuses to show users any of the website unless they happen to have the same version of IE that you are using right now!
The best type of technology is not a means to an end, it is an end in itself. Javascript is one of them.
OT Comment... (Score:2)
I have been investigating the use of XUL/XPCOM/Javascript for the creation of a user application with a database backend (after "discovering" how XUL works in Moz). However, I have ran into a bit of a stumbling block.
The application I am wanting to develop will replace a current 2-tier application based on VB/Access. What I wanted to do was create a front-end using XUL/Javascript to access (initially, but would be migrated to PostgreSQL later) the MS Access DB via ODBC - however, I haven't been able to find a way to do that which doesn't flag security (I even tried a convoluted method of creating a java applet that referenced a java application class that used JDBC to connect, but when it tried it throws an access violation error).
I understand the reasons this is happening (sandbox model and all) - and I ran across many people seeing this same problem. The only solution I could think of was essentially going toward a CGI-style 3-tier model - having the Javascript communicate to the backend scripts (most of the examples used Java servelets, but I imagine the same could be done using CGI) via HTTP, which would then pass the info back via the same route which the Javascript would present back to the user.
Is this truely the only way? For a long term solution, realize that this is what I want to do, but the initial conversion I am doing is really for a demo (to show the PHB's what can be done), and I don't really want to go through the whole trouble of trying to set up a backend server for a demo which might not even get the project the go-ahead (plus the attendent task of getting the permission to do it anyhow).
Thank you for any response you can give...
Previous Editions Were Great (Score:4, Insightful)
I'm glad to see this one has shifted focus from developing for each browser's quirks to developing for the W3C's DOM specifications.
I'll be picking this up from Half-Price Computer Books [halfpricec...rbooks.com] to replace my tattered copy of the previous edition.
As an aside, O'reilly's HTML: The Definitive Guide is not a good guide at all, IMHO. There are much better books out there. But the true definitive guides are the HTML 4.01 [w3.org] and XHTML 1.0 [w3.org] ( or XHTML 1.1 [w3.org] -- module-based 1.0) specifications.
You can pick just about any page on the web and learn the essentials of XHTML markup. The specifications are easy enough to read that they are really the best next step to mastering markup.
Safari (Score:4, Informative)
Thanks to safari.oreilly.com [oreilly.com] I've been reading this book for the past few days. I didn't even know it was just recently published.
An excellent book though. It reads well (as do most oreilly books I've found) and is very informative. I'm new to JavaScript but am picking it up very quickly thanks in large part to the quality of this book.
4th Edition (Score:4, Funny)
In response to Javascript flamers (Score:2, Redundant)
A lot of people have been labeling Javascript as flashy and only useful for flashy stuff and pop-up windows.
- This is just not plain true. Example: Any time you are on a site that doesn't require reloading (which I find very annoying) when you pick a selection and it filters another selection is using javascript. For example, say I am looking for stores located in my area. It asks me what state I am flying from. I choose "Ohio". Then I have to choose a city. I don't want to see "texas" in there, so Javascript filters down "Toledo, Columbus, Cincinatti, Cleveland". The alternative would be to load the page again, but who wants to have to sit through that? That's a lot less efficient.
The problems I see with javascript:
1. The other 10% that don't use IE.
2. It's about the worst technology to "program" in. Debugging bites, DOM is somewhat cryptic, you really DO need a book like this one.
3. It can be used for annoying things (like popups or whatever)
Even despite those problems, without javascript it would be REALLY difficult to make a good web application. Using postback is just so inefficient in that it wastes the servers resources. You can still do "business logic" in the middle tier with technologies such as "Remote Scripting" or IE's Dynamic Web Service Behavior (which creates a proxy to a server page). Other non-ms alternatives would be to create a java applet and do HTTP to other pages and interact with the result via javascript.
I am not really even against javascript on public internet sites so long as they are done right. Public sites should NEVER assume an IE browser, and always give a usable alternative. It just makes the user experience a lot better in my opinion.
a problem with javascript (Score:2)
1. The other 10% that don't use IE.
As that one in ten who refuse to use M$ for anything more than talking to leagacy equipment, people like you are my biggest problem. When you make some silly page that does not follow recognized standards from folks like W3C, I end up not being able to use your site. This usualy means that I have to run up your company's 1-800 bill or that I simply don't buy what you are trying to sell. Throw away 10% of your customers if you dare.
Consider also that much more than 10% of your potential customers are not IE users. People who bother to either download a superior browser or replace their whole OS are tech savy people likely to buy consistently. IE users are either clueless or lazy. The clueless are subject to all the FUD the popular press and M$ can generate about how insecure the internet is and other such nonsense. The lazy are less likely to do ANYTHING and therefore are less likely to purchase anything. Good for them, bad for you. I can't imagine a physical store where the owner would tollerate a clerk who ran off one in ten customers, especailly if they were people who took pains to be neat, orderly and polite.
By your own admision, you are opinionated and subject to swings. You say, " I used to be totally anti-javascript. But I've since reconsider my position on it." Reconsideration is a good thing. Extreem positions are foolish. It's not hard to program to recognized specs. Please, for your own sake, try to do so then work in all the annoying M$ only junk you want in such a way that does not make your site suck for me.
Re:a problem with javascript (Score:2, Informative)
As that one in ten who refuse to use M$ for anything more than talking to leagacy equipment, people like you are my biggest problem. When you make some silly page that does not follow recognized standards from folks like W3C, I end up not being able to use your site. This usualy means that I have to run up your company's 1-800 bill or that I simply don't buy what you are trying to sell. Throw away 10% of your customers if you dare.
I am not saying that the other 10% should not be thrown away. I'm saying that, if javascript is used, public site designers should also consider the other 10% and allow the site to still be usable (re-read my post.. I think you must have got a little excited).
Another thing- by your own admission you say that extreem positions are foolish and that its "not hard to program to recognized specs". First, I'd venture to say that you're breaking your rule given your comments about "all the annoying M$ junk". Unfortunately companies like Microsoft (and NETSCAPE) usually find it hard to program to the recognized specs, because they are lagged so far behind. This is a large reason why things have been incompatible in the past with javascript.
My advice: take a chill pill and don't be such a zealot. This attitude is childish.
What do I do with... (Score:2)
The Definitive Guide, 3rd Edition?
The Definitive Guide, 2nd Edition?
The Definitive Guide, 1st Edition?
Will the real JavaScript The Definitive Guide please stand up.
Much less definitive Guide? (Score:2)
I'd pay $10 for that 1 page document
art and one-button-games in javascript (Score:2)
associative arrays in JS (Score:3, Informative)
what it fails to point out is that you can do exactly the same thing with a standard array object (just because it IS an object). so, you can do this:
the latter seems more "intuitive." a bit of a blunder, i think. at the very least, the topic should have been discussed in a "definitive" guide.
beyond that, i've found the book useful but a bit bloated. it doesn't fit in my laptop case as well as the 3rd edition did! ;-)
mp
Re:associative arrays in JS (Score:2, Informative)
You are right that arrays in JavaScript are objects, but so are strings, dates, regular expressions, and just about everything. The array operator returns the named property of an object. This is different from the index of an array.
What do you think the following code will display?
The correct answer is nothing, nada, zip. That's because newVar[nameString] is an object property, not an array element. None of the array properties or methods will work on it, and mixing up object properties and array elements will make you a very mixed-up programmer.Re:associative arrays in JS (Score:2)
The book fails to point this out because it is bad code.
You are right that arrays in JavaScript are objects, but so are strings, dates, regular expressions, and just about everything. The array operator returns the named property of an object. This is different from the index of an array.
What do you think the following code will display?
The correct answer is nothing, nada, zip. That's because newVar[nameString] is an object property, not an array element. None of the array properties or methods will work on it, and mixing up object properties and array elements will make you a very mixed-up programmer.
since your argument applies to such arrays implemented as objects, it appears you are arguing against using associative arrays at all, period, in javascript. that doesn't make sense to me. using objects as associative arrays is a hack, so don't use them? well, you're entitled to that opinion but i think you're wrong.
i also think you miss the point. even if your argument is a valid reason not to use array objects to create associative arrays, the fact is that a lot of people do it -- and a "definitive" guide should be covering this practice, even if only to put it down to bad practice & explain why it should not be done.
mp
The best Javascript trick in the book (Score:3, Insightful)
What possible excuse is there for that? You may think you're serving 90% of internet users, but what about people who use IE with Javascript turned off? There really aren't any statistics about that, but I would imagine there are a lot of people who have, because it effectively removes the very annoying popups, traps that don't let you use your back button, stupid sites that try to prevent right clicking on images, etc.
If you use Javascript to create some cool effect, or use it as a navigation helper to save your user clicks, that's great, but at the very least take the time to make it work with browsers that have it turned off. You simply have no idea how many people that is, so why take the risk of alienating a large percentage of potential visitors?
Re:The best Javascript trick in the book (Score:2)
Actually I do know how many it is, from my log files.
It's actually a much smaller group than you think it is.
I don't have the stats with me at the moment, but that's ok because it's a fraction of a fraction of one percent.
How do I know from the log files?
Because if you don't have Javascript enabled, there is a cgi call that doesn't take place when the page is loaded. So instead of 1 page log entry view plus graphics, plus a cgi call, It shows without the cgi call, and that's a non-enabled (or unsupported) visitor that can't see the page the way it should be, or operate it the way it should.
My greater concern is for the visually challenged who can't operate my javascript... but that is coming along (in time, but not fast enough).
I have more compassion for the later, than I do for someone who simply turns off javascript, for whatever reason.
Javascript is an enabling technology, unfortunately there are some who abuse it, that doesn't mean that everyone should stop using it.
Re:The best Javascript trick in the book (Score:2)
If you check my past posts, I don't have much sympathy for any MS induced errors/bugs/infections.
NIMDA only spreads through three vectors, Microsoft Servers, Microsoft Operating Systems, Microsoft Browsers.
Nope, no sympathy. Only a ton of frustration, that ''marketing'' can beat solid business practices, and good programming.
I have the "Beta" of the First Edition (Score:2)
I bought it online when NS3 just came out, and i freaked when i saw you could change the image src dynamically! Finally, you could do something cool with JavaScript besides form validation. When i saw that, i saw the future of the industry, and figured JavaScript in web browers would eventually subsume Visual Basic apps.
O'Reilly was selling it online only, and released a Beta version, due to "fast-changing" info.
This is a good book. I may actually get this Ed. for fun.
Browser compatibility (Score:2, Informative)
The IRT JavaScript FAQ [irt.org] is a surprisingly comprehensive list of FAQ and "how do I..." type questions for JavaScript. I find myself relying very heavily on it for snippets of code.
Once you've "learned" JavaScript, a site like this is great when you don't want to reinvent the wheel or spend 20 minutes skimming a book trying to figure out why something works in Netscape but not IE...
Javascript is not just for browsers anymore! (Score:2, Informative)
Re:if you use JavaScript, you're a tool (Score:4, Funny)
Re:JavaScript/ECMAscript is EVIL (Score:2)
Re:Turn off javascript (Score:2)