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 bc
bottom ISBN / barcode area |
The ISBN printed on the back cover above the barcode says: 978-1-491-92580-5t
I'm pretty sure the "t" at the end is a typo as I've never seen a small letter (or any letter other than "X") in an ISBN. Also, the barcode below it does not contain a "t". Apologies if this is some new code format I'm not aware of yet.
|
tcordes |
May 13, 2017 |
| Printed |
Page 14
Figure 2-3, left diagram |
Two of the three color names of the sections that have an overlap of two colors are incorrect. They both say "Yellow", when they should say "Cyan" and "Magenta".
|
tcordes |
Sep 13, 2018 |
| PDF |
Page 14
Chart |
Figure 2-3 shows two charts, the one on the left, labeled "Additive colors (lights)", has its cyan section and its magenta section mislabeled as "Yellow".
|
Brian Dague |
Apr 10, 2019 |
| Printed |
Page 40
Figure 3-2, and 3-3 |
Figure 3-2 (page 40) and figure 3-3 (page 42) should have both their images and labels swapped. As it stands, the surrounding text does not refer to the correct figure.
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 44
6th paragraph from the bottom |
"it's entirely binary, leaving room for..."
should be
"it's entirely binary, leaving no room for..."
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 44
4th paragraph from the bottom, 1st sentence |
"the tRNS chunk" is used here for the first time (and only used on this page and nowhere else I believe), yet it is not defined. A few pages earlier many other chunks are listed and defined, but not tRNS. Perhaps it could be fixed by just changing the wording here:
"...information to a chunk named tRNS", or "...information to a chunk dedicated to transparencies called the tRNS chunk".
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 45
4th paragraph, 1st sentence |
English punctuation nitpick:
"image formats on the Web, GIFs and PNGs"
should be
"image formats on the Web: GIFs and PNGs"
Lists are preceded by a colon. With a comma it could be read in an incorrect and amusing way.
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 92
HTML code, 2nd last line |
Minor formatting glitch: the final line starting with "stroke" is missing the extra space before it compared to all the other "stroke" lines above it.
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 114
3rd paragraph from the bottom, 1st sentence |
"HTML holds an mix of"
should be
"HTML holds a mix of"
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 116
4th paragraph, 3rd sentence |
"Instead of erring, browsers automatically apply fixes..."
"erring" really doesn't seem like the correct word here. The browser doesn't really "err" in the sense implied. In fact, you could imply that by applying fixes the browser is always erring in a sense.
Perhaps it really needs to be spelled out like: "Instead of showing an error message..."
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 128
3rd paragraph, 2nd sentence |
"...to indicate an image should only be loaded"
What does "loaded" mean in this context? The paragraph is discussing ways to get images to *not* be downloaded. So if "loaded" means "downloaded", then the sentence is incorrect.
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 133
final line |
"Our JS code, regardless if it's written..."
is awkward English; try:
"Our JS code, regardless of whether it's written..."
better yet:
"Our JS code, whether it's written..."
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 153
4th paragraph (excluding math lines), last sentence |
"but it reduces battery life, memory use, and precious CPU cycles"
Above that line, it says memory usage is reduced by 25% but GPU does "a little more work". Then the above list is used to illustrate the benefits, and one of the benefits is reduced battery life? Either it should say "battery use" or "battery drain" if you want to say the effect on the battery is beneficial.
Even then, since the GPU must work harder, isn't it possible battery use is negatively impacted, and so not a benefit, and thus should be excluded from this list. Besides the speed and memory footprint, I'm not sure it's easy to guess whether the change proposed can lead to any inference regarding battery without running empirical current draw tests.
|
tcordes |
Sep 13, 2018 |
| Printed |
Page 168
1st paragraph, last sentence |
"Not only is this now an HTTP request"
should be:
"Not only is this now one HTTP request"
or perhaps:
"Not only is this now just one HTTP request"
|
tcordes |
Sep 17, 2018 |
| Printed |
Page 168
1st paragraph, last sentence |
"it also reduces the cache footprint to 3.6 KB"
I'm not sure what that number is derived from. If the image is 12.8 KB, wouldn't the "cache footprint" necessarily be larger than 12.8 KB (raw file plus overhead)? Perhaps the problem is the word "footprint", which is not defined. Perhaps the author meant 3.6 KB cache overhead? Still, the same problem exists: where does the 3.6 KB number come from.
|
tcordes |
Sep 17, 2018 |
| Printed |
Page 169
CSS code block vs page 170 HTML code |
On page 169, the CSS is showing how to use sprites from a file named browsers-sprite.png (line 6). But the CSS classes named just below it are social media platforms, not browsers. This is not consistent. Page 168 also mentions browsers (not social media) in the "convert" command line example.
Then on page 170, in the HTML, you finish the example with the classes now named (correctly) for the browsers, like "icon-firefox".
But further, on page 170, 1st text paragraph, it's again conflated with the erroneous text: "the social media links clickable".
These three pages need to be made consistent.
|
tcordes |
Sep 17, 2018 |
| Printed |
Page 191
figure 10-14, 1st blue box in 1st column |
"or can you handle come complexity"
should be:
"or can you handle some complexity"
and directly beneath it:
"Complxity is fine"
should be:
"Complexity is fine"
|
tcordes |
Sep 17, 2018 |
| Printed |
Page 210
1st paragraph, 3rd sentence |
"were missing from the preceding example"
There is no preceding example of <picture>, or anything else that has a nested <img> tag. I believe that "preceding" should have been "following", or some other verbiage. The example in question is actually on the following page.
In fact, the text on pages 210 and 211 seem a bit convoluted in terms of how/when they introduce brand new concepts/code. The first two sentences on page 210 almost sound like they are meant to come after the initial <picture> code example. If the whole paragraph came after the <picture> example, then "preceding" actually makes sense. Perhaps this was the original order before editing.
|
tcordes |
Sep 17, 2018 |
| Printed |
Page 217
JS code block, 3rd line |
"var sizes support = "
should be:
"var sizesSupport = "
|
tcordes |
Sep 17, 2018 |
| Printed |
Page 219
1st paragraph, 1st sentence |
"the future existance"
should be:
"the future existence"
"existance" isn't in any dictionary, even as a variation, even though it is moderately common.
|
tcordes |
Sep 17, 2018 |
| Printed |
Page 223
Step 1, 1st sentence |
"To start the exchange, the client would"
should be:
"To start the exchange, the server would"
It is clear from the text above and the example below that it is the server that sends the Accept-CH header.
|
tcordes |
Sep 17, 2018 |
| Printed |
Page 236
PHP code block, last 2 lines |
Those last 2 lines are really messed up, invalid PHP code. PHP code uses dot notation for string concatenation, not plus signs (seen in the first line), or worse, no concatenation symbol at all (seen at the end of both lines).
Also, it is not clear what the format of the "CH" cookie's value is supposed to be. In the JS code on the subsequent page there is an equals sign after "Viewport-Width", but there is none in the PHP code. I suspect the formats should match.
In the last line it's unclear what the "1" character is doing there with the $dpr. Perhaps it is the $dpr that is superfluous there and the value should actually just be the aforementioned "1".
|
tcordes |
Sep 19, 2018 |
| Printed |
Page 247
PHP code block, lines 4 and 7 |
"$brwoser_ver"
on both lines should be:
"$browser_ver"
Also, closing parenthesis is missing from both lines' IF expression (after the "6").
|
tcordes |
Sep 19, 2018 |
| Printed |
Page 262
2nd math block, 1st line |
I'm unclear on why the first math block uses 100,000 base images as an example, but the second math block uses 10,000. Should they not match? Even if you're somehow reducing the count by "focusing on just the 300x breakpoint", there's 8 total breakpoints in the referenced figure 13-1, so you'd reduce 100,000 by 1/8, not 1/10.
Also, the second math block doesn't make sense, with the incoherent modification of 'x' multiplication from the formula above into "+" and "=" signs that are mathematically false.
"960MB + 672MB + 627MB + 672MB"
does not "="
"720MB + 504MB + 504MB + 504MB"
The final number (8.93) seems to be the addition of all lines that start with an equals sign, but there's no formula or explanation of why.
It is completely unclear where these numbers are being pulled from in most cases, and referencing a figure 20 pages prior doesn't help the situation. Where 12.1KB comes from is a mystery as that precise value appears nowhere in figure 13-1.
The whole second math block should be reworked to mirror the formula above it, or, if it's not intended to be based on that formula, to show where all the numbers are coming from in each step, and how they relate to the previous/following line mathematically, and what they represent in English terms.
|
tcordes |
Sep 19, 2018 |
| PDF |
Page 288
Second paragraph (Resolution section) |
Hi!
Thanks for such amazing book!
But a cannot agree with the contents of "Resolution" section on 288 page (Chapter 14: Operationalizing Your Image Workflow).
Author says that it's important to look at DPI metadata of the raster image (JPEG in this example).
DPI in raster images is used only for printing (to calculate physical image dimentions on paper), it doesn't change anything in the image pixels itself. The only thing that matters is pixel size (width and height).
Explanation in the book is misleading and should be removed or changed.
Example: DPI resolution is the metadata value which is used for printing, just ignore it and look at pixel dimentions.
Best wishes, Nick.
|
Nick Lavlinsky |
Dec 06, 2016 |
| Printed |
Page 321
last line |
"Very: DPR"
should be:
"Vary: DPR"
|
tcordes |
Sep 19, 2018 |