The errata list is a list of errors and their corrections that were found after the product was released.
The following errata were submitted by our customers and have not yet been approved or disproved by the author or editor. They solely represent the opinion of the customer.
Version |
Location |
Description |
Submitted by |
Date submitted |
Printed |
Page 4
1st paragraph, 3rd line |
"coated adhesives" is probably erroneous. The author almost certainly meant 'coated abrasives'. That would make sense in the context, being concomitant with 'grain size' which occurs in the preceding text.
'Coated abrasives' is a generic term for a range of products which include 'sandpaper'. The abrasive 'grains' are held in place by a 'coat' of 'adhesive'.
|
Richard Elderton |
Oct 27, 2009 |
Printed |
Page 4
1st paragraph, 3rd line |
Sorry, I made a mistake yesterday. The term 'coated' here refers to the fact that the backing material (paper, in the case of sandpaper) is 'coated' in abrasive grains using adhesive, not that the backing is coated with adhesives, so my entry should read as follows.
"coated adhesives" is probably erroneous. The author almost certainly meant 'coated abrasives'. That would make sense in the context, being concomitant with 'grain size' which occurs in the preceding text.
'Coated abrasives' is a generic term for a range of products which include 'sandpaper'. A coat of abrasive grains is fixed to the backing material by a layer of adhesive.
|
Richard Elderton |
Oct 28, 2009 |
Printed |
Page 15
Table 2-1 |
Microsft Internet Explorer 5, 5.5 and 6 isn't on either the Linux or
Unix platform.
|
Anonymous |
|
Printed |
Page 31
The paragraph before the heading "Fixed-Width Design" |
The text claims that the em unit is "a unit used in printing to refer
to the width of one capital letter M". This is not so, either by definition
or by practice coincidence.
You can see the practical incorrectness simply by comparing the width of
"M" with a box with declared width of 1em, using different fonts. The
proportion greatly varies by font, but generally "M" is clearly narrower
than 1em, often (e.g., in Courier New) much narrower. I wonder why the
incorrect statement gets repeated so often, when it can be falsified so
easily. (There is a _historical_ connection between "M" and the em unit,
but that's a different story.)
The incorrect statement is repeated on p. 292 in Table 16-1.
|
Anonymous |
|
Printed |
Page 40
link example at end of "Use media types" section |
|
Anonymous |
|
Printed |
Page 49
second to last paragraph |
img src="../../daisy.gif" points to daisy.gif in the users directory.
directory 'pers' is the current directory; 'jen' is one level up; 'users'
is 2 levels up.
|
Anonymous |
|
Printed, |
Page 49
Third indented code snippet |
On page 49 of Web Design In a Nutshell, the author writes:
"Image tags also use pathnames to point to the graphic file to be displayed. For instance, this image tag in the art.html document:
<img src="../../daisy.gif">
points to a graphic named daisy.gif located in the jen directory. Two uses of ../ indicate that the graphic file resides in a directory two levels higher than the current document (art.html)."
But in this example, "../../daisy.gif" means the graphic file would reside in the users directory, not the jen directory. For the graphic to reside in the jen directory the code would need to be "../daisy.gif"
|
Anonymous |
Jun 24, 2010 |
Printed |
Page 54
middle of page |
a tar file is an "Archive file"; it is not a compressed file.
|
Anonymous |
|
Printed |
Page 73
2nd para in definition of "Character encoding" |
256 (28)
->
256 (2^8)
i.e., the 8 in 28 should be an exponent
|
jdgleeson |
Dec 06, 2009 |
Printed |
Page 133
1st paragraph |
URL for HTML 4.01 Transitional given as:
"http://www.w3.org/TR/html4.01/loose.dtd"
According to w3.org, it is supposed to be:
"http://www.w3.org/TR/html4/loose.dtd"
The error lies is the book using ". . . html4.01" rather than ". . . html4"
I'm a beginner, but (un)fortunately obsessive ; -)
|
Anonymous |
|
Printed |
Page 139
5th paragraph |
The author gives this example of identifying media type and character encoding:
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
I inserted the exact code in my own webpage. When it came time to have the W3C Markup Validation Service [http://validator.w3.org/] validate my code, it brought up numerous errors related to code that I had copied from Robbins' book -- including from the code I've typed in, above.
A link from one of the error explanations provided by the W3C Markup Validation Service [http://www.cs.tut.fi/~jkorpela/html/empty.html] showed the problem: apparently, the "/>" ending notation Robbins uses (see her code, above) is not valid in HTML4.01 or lower -- it is only acceptable in a document that is 100% XHTML.
My explanation may not be 100% technically accurate, as I'm new to webdesign and HTML. However, I would urge you to check this for yourselves, by entering the above code at the W3C Markup Validation Service, and then reading the explanatory document provided by that validation, which says (3rd point):
"using XHTML-style self-closing tags (such as <meta ... />) in HTML 4.01 or earlier. To fix, remove the extra slash ('/') character. For more information about the reasons for this, see Empty elements in SGML, HTML, XML, and XHTML."
|
Anonymous |
|
Printed |
Page 146 ff
many pages |
Throughout, the following construction or similar is used...
"Attributes
Core (id, class, style, title), Internationalization, Events"
However, nowhere is it clearly stated what this means. "Core" is not even in the
index.
|
Anonymous |
|
Printed |
Page 166
middle of page |
The attributes 'size' and 'width' for the element <hr> are reversed (either the
labels or the definitions):
'width' is the length of the rule across the page/screen (in the horizontal
direction).
'size' is the thickness of the line (in the vertical direction).
|
Anonymous |
|
Printed |
Page 170
Top of page, comtinuation of attribute list |
rel = "relationships"
rev = "relationships"
rev = "reverse relationships" is better for rev definition
|
Anonymous |
|
Printed |
Page 181
First paragraph under figure 12-2 |
Safari DOES display alt attribute values but will only do so if you have stipulated a
width and height for the image large enough for the text to display.
For example: <DEFANGED_IMG src="example.gif" alt="An example image." width="130"
height="130">
|
Anonymous |
|
Printed |
Page 187
3rd paragraph |
It seems that
type="image/x-icon" has been deprecated.
Refer to
http://en.wikipedia.org/wiki/Favicon#Standardization_and_implementation
|
Anonymous |
Oct 07, 2009 |
Printed |
Page 223
Scope (from second paragraph down) |
The possible attributes of scope are: row, col, rowgroup and colgroup.
"column" is not a valid attribute as both the text and the code example suggest.
|
Anonymous |
|
Printed |
Page 253
Fifth line down |
As far as I know, the 'value' attribute is not required for password text fields. This page also confirms that:
http://w3schools.com/tags/tag_input.asp
|
Anonymous |
|
Printed |
Page 258
Example at the top of the page (above the graphic) |
The 'name' attribute is required for the image input element, yet the example doesn't have it.
|
Anonymous |
|
Printed |
Page 258
Example at the bottom (above the graphic) |
The example has two omissions:
* The <form> element is missing 'action', a required attribute.
* The <input> element is missing 'name', a required attribute.
|
Anonymous |
|
Printed |
Page 268
Example at the top of the page |
The example has this CSS:
input.required {background-color: darkred; color: white}
While 'darkred' is accepted and supported by most browsers, it is not a valid color value according to the W3C CSS validator.
|
Anonymous |
|
Printed |
Page 299
"Adjacent Sibling Selector" section |
The example in this section has "H1" (capital H) instead of "h1" (lowercase h).
|
Anonymous |
|
Printed |
Page 301
paragraph5 |
"element[attribute~="value"]
Example: img[title="grade"] ..."
:Missing tilde in the Example?
|
Anonymous |
|
Printed |
Page 306
3rd table entry |
The pseudoselector is listed as ":firstchild", when it should be ":first-child".
|
KatieK |
Aug 02, 2010 |
Printed |
Page 316
Top code example |
Second nested list show incorrect placement of </li>. Code should look like this:
<p>Lorem ipsum dolor sit amet.</p>
<ul>
<li>Lorem ipsum</li>
<li>Dolor sit amet</li>
<li>
<ul>
<li>Consectetuer adipiscing</li>
<li>Elit pellentesque
<ul>
<li>Pharetre urna</li>
<li>In laoreet tincidunt</li>
</ul>
</li>
</ul>
</li>
</ul>
|
Anonymous |
|
Printed |
Page 319
Last paragraph |
The text (and the associated image on p. 320) does not correspond to CSS
specifications, and even less the CSS implementations.
CSS 2.1 says:
"A value of 'normal' selects a font that is classified as 'normal' in the
UA's font database, while 'oblique' selects a font that is labeled 'oblique'.
A value of 'italic' selects a font that is labeled 'italic', or, if that is
not available, one labeled 'oblique'.
The font that is labeled 'oblique' in the UA's font database may actually
have been generated by electronically slanting a normal font."
http://www.w3.org/TR/CSS21/fonts.html#propdef-font-style
There is no reference to displaying a normal font "on a slant using mathematical
calculations". (In clause 15.2, CSS 2.1 says that for 'italic', if there is no
italic face, oblique shall be used, but this too deals with font faces.)
In implementations, 'italic' and 'oblique' are synonymous, and an italic or
oblique face will be used if available, otherwise algorithmic slanting is
applied to a normal face, often resulting ?n awkward results (e.g., for a
character like "|"). At least this is so on all versions of Internet Explorer,
Netscape/Mozilla, and Opera that I have ever used.
I have no idea why the book says that "At all small text sizes on low resolution
monitors, italic and oblique text look exactly the same". Are they any conditions
where they do _not_ look exactly the same, on CSS-styled web pages? How was
Figure 18-7 on p. 320 created? I suspect it was created using a typesetting
program that is able to slant a font.
|
Anonymous |
|
Printed |
Page 345
Para beginning "The four margin properties . . ." |
In the sample code: {margin: 3px 20px 2px 20px; } ,
the third value should be 3px.
|
Anonymous |
|
Printed |
Page 347
First paragraph in "Borders" section |
The third sentence in the paragraph begins with "As for margin...", but I think you meant to say "As with margin...".
|
Anonymous |
|
Printed |
Page 361
bottom of page |
In the Values for background-position, second line near the end, the right
curly brace '}' should be a right square bracket ']'.
|
Anonymous |
|
Printed |
Page 362
bottom of page |
In/after the second paragraph under the heading 'Keyword positioning' the CSS
code does not match figure 20-7 on the following page. Either the code or the
figure should be changed. The figure could be changed from:
+-------------+ +-------------+
| * | | * |
| * | to | * |
| * | | * |
+-------------+ +-------------+
or, change the code to:
{background-position: left top;}
{background-position: center center;}
{background-position: right bottom;}
Changing the code, however, negatively impacts the code examples in the first
paragraph of page 363. The first would become:
{background-position: center;}
and the second would not be usable as an example.
|
Anonymous |
|
Printed |
Page 364
Next to last paragraph |
There is an extra "the" in the sentence "This is the also the way background...". It should be "This is also the way background...".
|
Anonymous |
Mar 07, 2010 |
Printed |
Page 375
Line 2 of first code example |
h1 {clear: left; top-margin: 2em;}
should be:
h1 {clear: left; margin-top: 2em;}
|
Anonymous |
|
Printed |
Page 377
5th bulleted paragraph in section "Containg Blocks" |
Last sentence:
"For right-to-left languages, it goes from top-left corner of the first
line to bottom-left corner of last line."
I believe should probably read:
"For right-to-left languages, it goes from top-right corner of the first
line to bottom-left corner of last line."
That is, "top-left" changed to "top-right".
|
Anonymous |
|
Printed |
Page 378
Figure 21-8 |
For the image to be 100% from the top of the containing block, the top
of the image must be at the very bottom of the containing block (ie, the
image would be below the containing block).
This figure looks more like 40 or 50% from the top.
|
Anonymous |
|
Printed |
Page 382
code line, immediately above figure |
reads:
clip: rect(10px, 130px, 130px, 10px);}
should be (to match figure):
clip: rect(10px, 130px, 10px, 130px);}
(switch last 2 values)
|
Anonymous |
|
Printed |
Page 385
first paragraph, second line |
'strong' should be 'span'
|
Anonymous |
|
Printed |
Page 386
last paragraph, second line |
'relative' should be 'absolute' (to match the code in the middle of page 385).
|
Anonymous |
|
Printed |
Page 413
second paragraph, second line |
'after' should be 'before'
"...initials are inserted before each del element..."
|
Anonymous |
|
Printed |
Page 417
code example before last paragraph |
"content:" and ";" are missing on first line of code example:
h2:before {counter(section) ": "
counter-increment: section; } /* defaults to 1 */
should be:
h2:before {content: counter(section) ": ";
counter-increment: section; } /* defaults to 1 */
|
Anonymous |
|
Printed |
Page 450
Figure 25-1 |
In the "CSS: Basic Box Properties" chapter, specifically, page 339 figure 19-1,it is
stated that the "width" quality should describe the content area alone. Padding,
border and margins are added to that to decide the final width of an element.
Figure 25-1 (and the verbal explanations that follow that) shows an element with
"width" set to 200px that seem to describe the width of both the content area and the
padding area (upper part of the figure).
I find it confusing that the padding should be included here.
|
Anonymous |
|
Printed |
Page 450
W3C Box Model diagram |
The page's code snippet defines the width as 200px, but the W3C Box Model diagram incorrectly implies it to be 160px.
As explained in the text, the padding of an element is *added to* its defined width, not subtracted from it. The W3C Box Model diagram is incorrect because it puts the padding (20px on each side) inside the element's width of 200px, whereas the padding should be added onto the element's width, just as the border width and margin are.
The paragraphs and code snippet are correct.
|
Jonathan Van Dusen |
Sep 18, 2010 |
Printed |
Page 450
Border Box Model diagram |
The Border Box Model diagram implies that the margin around the element gets squeezed into the 200px defined size. This is incorrect; even with the faulty box model the margin still goes outside the defined width.
Based on this error and the other error I submitted, this implies that the "Width" marker at the bottom of the diagram is too wide. 200px is the correct measurement but it shouldn't include the margin.
|
Jonathan Van Dusen |
Sep 18, 2010 |
Printed |
Page 481
Last section of code |
element.onlick = function() (
change();
}
"onlick" has already been corrected to "onclick" in the errata.
The trailing left parens should be a left brace.
element.onclick = function() {
change();
}
|
Anonymous |
Oct 10, 2008 |
Printed |
Page 482
first code section |
"onlick" should be "onclick" and the trailing left parens should be a left brace.
element.onlick = function()(
change(this);
}
-->
element.onclick = function(){
change(this);
}
|
Anonymous |
Oct 10, 2008 |
Printed |
Page 483
code example before last paragraph |
In javascript, the plus "+" operator associates from left to right.
In the alert statement we have an expression with: a string, a number, a number
and a string, which are "strung" together with the "+" operator. Evaluation of
this expression will be strictly from left to right.
First the first string and "sabine.age" will be concatenated (sabine.age will be
converted to a string and concatenated to the first string. Similarly, "dakota.age"
will be converted to string and concatenated to the previous string. Finally the
last string will be concatenated. The result is "98 treats", and not "17 treats".
To get "17" you would need to add parentheses around "sabine.age + dakota.age"
as in: "...give Dakota ' + (sabine.age + dakota.age) + ' treats,...".
|
Anonymous |
|
Printed |
Page 495
Second Code Block |
You set:
var div = document.getElementById('content').innerHTML;
Because innerHTML returns a string, div is a string. On the next line you write:
div.innerHTML += '...';
But if you do that, you would get an error because div is only a string and strings don't have the property innerHTML.
|
Anonymous |
|
Printed |
Page 495
3rd line of code from the top |
3rd line of code:
var div = document.getElementByID('content').innerHTML;
div.innerHTML += '<p>This is a paragraph added using innerHTML.</p>';
The var div should not have the innerHTML at the end of it.
Otherwise, the line after it would not work.
|
Salvatore Crapanzano |
May 13, 2009 |
Printed |
Page 495
3rd line of code from the top |
3rd line of code:
var div = document.getElementByID('content').innerHTML;
div.innerHTML += '<p>This is a paragraph added using innerHTML.</p>';
The var div should not have the innerHTML at the end of it.
Otherwise, the line after it would not work.
|
Salvatore Crapanzano |
May 13, 2009 |
Printed |
Page 596
"Data rate (bit rate)" section |
There are two errors regarding units in this section:
1. The second sentence contains:
"kilobytes per second (K/sec or Kbps)"
Kbps has a lowercase "b", which means it is kilobits, not kilobytes. You got this correct in the "Bit rate" section in the audio chapter (page 577), but it's wrong here. However, the use of "Kbps" in the last sentence of this section is correct.
2. You reference "K" five times in this section, but "K" is not a unit of measurement - it's a number. For instance, when you say "K/sec", you're giving the unit "thousand per second", which doesn't make any sense. You need to specify kilobits ("Kb") or kilobytes ("KB").
|
Anonymous |
|
Printed |
Page 715
Values in page-break-inside section |
The only values for page-break-inside are auto, avoid and inherit. always, left and right are incorrect.
|
Anonymous |
Oct 08, 2008 |
Printed |
Page 723
Nonstandard Entities section, last paragraph; The decimal character |
entities "&151;" and "&8212;" are both missing the # symbol.
|
Anonymous |
|
Printed |
Page 727-9
miscellaneous character entity tables |
The character entities for Capital Z, caron and Small z, caron (Ž and
ž), needed for Czech, are missing. The symbol for Greek capital pi (?) is
incorrect. "Ellipses" should be "Ellipsis" (the -es is the plural). The symbol for
the single left angle quotation (?) is incorrect. The single angle quotation
entities (? and ?) are both standard.
|
Anonymous |
|
Printed |
Page 731
Mathematical Operators section, bottom of page; The character entities |
sube and supe are missing semicolons.
|
Anonymous |
|
Printed |
Page 740
Table D-4; The RGB values for tomato, "253-99-71", should be "255-99-71" |
|
Anonymous |
|
Printed |
Page 754
SVG entry in Glossary; SVG is listed as "Standardized Vector Graphics" |
but should be "Scalable Vector Graphics" instead.
|
Anonymous |
|