I have found a tolerable number of errors in the book. It isn't perfect, it's disappointing that the errata page is not being kept up, and since it's the 5th edition it's difficult to excuse some of them, but overall I am very happy with the book and intend to work my way through the whole thing very thoroughly. It's sad that publishers cannot be bothered to have even one person do the same before publication, but such is the norm of the industry. Weeks spent waiting for someone to go over it equal lost sales, I suppose.

I tried to submit to the errata page, but the amount of personal information demanded and required to do so was excessive. I'm happy to submit the error, but not fill out a form with dozens of fields revealing my information for the privilege of proofreading their book for free.

The publisher could post errors from this forum into the errata if they cared to and obviously they do not.

Also, the error of the " -transitional.dtd”> " that should not appear at the top of the HTML code does appear in my book, which is a paperback printed book, not an ePub.

Aside from the above issues, I do like the book very much and highly recommend it. It is the best material I have seen that I would consider an orientation to the language and put does a good job of putting concepts into context.

Apart from the errors that you wrote about on the forum, do you remember (or probably you save them somewhere in a list) any other errors that you noticed?

I write them in the book, but I also write other stuff in the book, so not sure I will get them all on this list.

Chapter 1, p. 11
Insert this line before the alert("Second Script Block"); line:
document.bgColor="red";

Chapter 2, p. 41
The description of how parseInt() works/what it does is not correct. See my post in this forum. Also, extreme nitpick: the floating point is mistakenly called a "decimal" point, but decimal points are for base 10 only and this should be called a floating point or radix point.

Chapter 5, p. 105
The sentence that reads "However, these objects are not used very often, so we will not be discussing them further in this book." is false; Number objects are discussed on p. 134.

p. 106
Reads "Character positions start at 0. If you don't include the second parameter, searching starts from the beginning of the string." Should read something like:
Character positions start at 0. If you don't include the second parameter, indexOf() searching starts from the beginning of the string and lastIndexOf() searching starts from the end of the string.

Chapter 9, p. 234
Information is slightly out of date: current ECMAScript standard is edition 6, published in June 2015.

p. 253
Comment after var headElement; refers to it as "headingElement", should be headElement.

p.254
headElement is mistakenly called "headingElement" twice.

p.255
headElement is mistakenly called "headingElement" again.

p. 262
-transitional.dtd"> should be deleted

To avoid the discussed precedence issue, font: 12pt arial; should instead be:
font-family: arial;
font-size: 12pt;

p. 263
.newStyle should be .new-style

p. 264
The comment after divAdvert.style.top = "100px"; says "set the right position" instead of "set the distance from the top" as it should.

p.265
The description for the Animating Content program is incorrect. Reads "This page moves an element across a page from right to left." It should instead read something like "This moves an element back and forth across the page, starting from left to right."

Also, Arial is capitalized here, but was not in earlier examples. Both seem to work however.

That's where I am in the book at the moment.

I recall that there are some other minor typos, but none are jumping out at me right now. I will post here if I come across any.

Wow! I can't thank you enough. It turns out that you are a much more attentive and scrupulous reader than I am. I only started actively doing all the exercises from the book and before I just read the theoretical material and played around in the browser.
It would be really great if we (as it seems there are at least three active Javascript learners here - me, you and snowcrasher555) kept this errata forum up to date.
I also promise to post about any other error,inaccuracy or typo that I find in the book.
Javascript learners must unite! :)

I'm in! Looking forward to seeing what others come up with.

The errata section they pretend to have on this site is ridiculous. The one error they do have listed for this book doesn't even describe the error correctly, and it makes me angry that to submit an error I am required to provide my first and last name, email, make up a password, verify the password, give my complete home address, give my phone number, and answer question after irrelevant question, like they are somehow doing me a favor by letting me report their mistakes to them.

It's downright predatory and a clear attempt to harvest valuable data.

When I first saw the errata section I though:"Wow, just one typo has been reported on so far, that's how editors should work". I agree, that there could be someone responsible for updating the errata page based on what is being discussed on the forum. That would be both helpful for those who use this book to learn JS and would add points to the publisher's reputation.

Thanks very much for writing that detailed list of errata. I agree about the errata section and the form. I filled it out a few days ago, but I did not enjoy the process, and I can see it deterring me in the future: I shouldn't be asked for my number and address when I am submitting an error! With that said, that's on the publisher, and not the author, and I am appreciative of his visiting the forums and some recent threads like this one.

At some point, I may submit another errata form (and if I do, I will try to pack in as many as I find in these forums)

I'm being hypercritical but there are also some minor typos like the absence of a close parethesis. Example:
p 145. alert("My name is " +this.firstName+" "+this.lastName;
The above-mentioned part of the code is repeated three times on that page,each time without a close parenthesis.
Not a kind of mistake that might result in misunderstanding but I really hope that the next edition takes all of that into consideration.

Well there are certainly many more mistakes than the official errata leads one to believe. =)

I created a new Github repository (https://github.com/jwmcpeak/beginningjavascript5e) that has the source code for the examples, and I also added an errata document that contains Moby's list. I'll update http://beginningjs.com to include the errata sometime this week. This is an unofficial errata, meaning that these mistakes will not be fixed in any upcoming reprintings of the 5th Edition unless they are submitted through Wrox's form.

I understand your feelings regarding the questions you have to answer in order to submit errata. I seems excessive, and I mostly agree. However, they're also there to deter random, spammy, and obviously false errata. It takes time for Wrox employees and the authors to process errata, and Wrox wants to limit bad submissions as much as possible.

When I can, I'll submit these. Thanks for sharing them, Moby.

@Wilfred,

You're not being hypercritical at all. Missing a closing parenthesis is a major error; one that shouldn't have made it into print.

__________________
Jeremy McPeak
Author of:
Professional Ajax, 2nd Edition
Beginning JavaScript, 4th Edition
Beginning JavaScript 24-Hour Trainer

http://www.wdonline.com

My Twitter

I find it extremely difficult to believe that insisting that I provide my first and last name, email address, phone number, and complete physical address is necessary for preventing false errata reports. How many people are really going to ferret out the place to report errors and go through the steps to provide the actual relevant data--book title, edition, page number, error description, and ISBN--to spam the publisher? Yet they won't bother to just make up a fake name, address, email, and phone number?

How about a spam filter, Wrox? Do we need to write you one?

And why is it more important to discourage these mythical fake reports than it is to make reporting real ones as easy as possible? Yet I'm not supposed to be able to protect myself from the onslaught of email spam, solid spam filling my house via mail slot, and pestering spam calls?

I call BS. My data set of name, address, email, and phone number has cash value for marketers and the harvest attempt is low and scummy, indicative of the preference to get that fraction of a penny over a desire to improve future editions of the supposed product. Why just sell books when we consumers can be products too?

A normal attempt to make sure that reports are genuine could include an email that must be replied to to confirm. There is no need for my address. There is no need for my phone number.

Don't try to cover for them, McPeak. I wasn't thinking of you as part of the problem and you don't have to be.