Errata

CSS: The Definitive Guide

Errata for CSS: The Definitive Guide, Fourth Edition

Submit your own errata for this product.

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.

Color Key: Serious technical mistake Minor technical mistake Language or formatting error Typo Question Note Update

Version Location Description Submitted by Date submitted
Printed Page xxii
7th paragraph (last example)

In the last example on this page:

[[Alpha || Baker || Cray ], ]{2,3} and Delphi

The explanation begins with:

Two to three of Alpha, Baker, and Delta must be followed by and Delphi.

I believe the explanation should read:

Two to three of Alpha, Baker, and Cray must be followed by and Delphi.

Amber Matz  Aug 19, 2019 
Printed Page section 2.1.2
the last two sentences

The description in that section:
If you use an incorrect property or value in a declaration, the whole rule will be ignored.

may should be:

the declaration will be ignored.?

sdutwsl  Sep 15, 2020 
ePub Page 7. Basic Visual Formatting>Altering Element Display>Using auto
3rd paragraph

The error:
"In the case where all three properties are set to something other than auto—or, in CSS terminology, when these formatting properties have been overconstrained—then margin-right is always forced to be auto. This means that if both margins and the width are set to 100px, then the user agent will reset the right margin to auto. The right margin’s width will then be set according to the rule that one auto value “fills in” the distance needed to make the element’s overall width equal that of its containing block. Figure 7-11 shows the result of the following markup:"

explanation:
If all properties are defined and none of them are "auto", the user agent will not reset the right margin to "auto".

Anonymous  Sep 08, 2022 
ePub Page 57
Figure 2-18 source code

The source code is missing the closing </tr> tag

Note from the Author or Editor:
I can’t tell if this is correct or not, since apparently he’s talking about the actual source markup in the ePub version.

don matthews  Mar 29, 2019 
PDF Page 105
Figure 3-6 caption

As the authors suggest, zero specificity beats no specificity is kind of counter-intuitive, in that zero is generally considered the minimum (natural) number.

I would recommend to change the wording to something like "better than none" or "zero beats none" or "zero beats inherited/default", to preserve the intuition that zero is the minimum.

Wei Lin  Jan 27, 2020 
Printed Page 111
3rd paragraph (just before heading "Non-CSS Presentational Hints")

Quote: "A link can't be an unvisited hovered active link <italics>and</italics> an unvisited hovered active link"

Naturally, a link CAN be both of those things, because they're the same. Based on the relevant code sample (below), I believe that the second one should read "visited hovered active link"

a:link:hover:active {color: orange;}
a:visited:hover:active {color: silver;}

Tyrel Clayton  Jan 03, 2021 
PDF, Page 118
bottom code block

@import url(../special/toppings.css);

should be

@import url(../toppings/special/toppings.css);

Anonymous  Sep 20, 2021 
Other Digital Version 129
bottom

div {width: 50vh; height: 33vw; background: gray;}

should be

div {width: 50vw; height: 33vw; background: gray;}


"A div! It is half the width of the viewport and a third the height." from https://github.com/meyerweb/csstdg4figs/blob/master/04-values-and-units/css4_0407.html

jinbeom hong  Sep 22, 2021 
, Other Digital Version Page 129
bottom

div {height: 50vh; width: 33vh; background: gray;}

should be

div {height: 50vw; width: 33vh; background: gray;}

From https://github.com/meyerweb/csstdg4figs/blob/master/04-values-and-units/css4_0407.html

The div's width should be half of "width" and div's height should be third of "height".

jinbeom hong  Sep 22, 2021 
Printed Page 159
first code

There is needless space at the end. So,

local("SwitzeraADF-Regular ")

should be

local("SwitzeraADF-Regular")

jinbeom hong  Sep 26, 2021 
PDF Page 167
2nd paragraph

The stylesheet below lacks quotation marks here and there:

h1 {font-family: 'SwitzeraADF Extra Bold, sans-serif;}
h2 {font-family: 'SwitzeraADF Bold, sans-serif;}
h3 {font-family: 'SwitzeraADF Bold', sans-serif;}
h4, p {font-family: SwitzeraADF Regular, sans-serif;}
small {font-family: 'SwitzeraADF Light', sans-serif;}

It should be like this as recommended in this book:

h1 {font-family: 'SwitzeraADF Extra Bold', sans-serif;}
h2 {font-family: 'SwitzeraADF Bold', sans-serif;}
h3 {font-family: 'SwitzeraADF Bold', sans-serif;}
h4, p {font-family: 'SwitzeraADF Regular', sans-serif;}
small {font-family: 'SwitzeraADF Light', sans-serif;}

Charles  Feb 23, 2020 
PDF Page 191
top

body {font-family: Verdana;}

should be

body {font-family: Futura;}

jinbeom hong  Sep 28, 2021 
PDF, ePub Page 195
top of page

the font-feature-settings descriptor
->
the font-feature-settings property

jinbeom hong  Sep 28, 2021 
Printed Page 203
First paragraph of Inline-Axis Properties section

padding-inline-end is repeated three times. It should read padding-inline-end, border-inline-end, margin-inline-end.

Stuart Sewell  Aug 13, 2023 
Printed, PDF, ePub, Page 210
text-indent's percentage value inheritance

According to https://www.w3.org/TR/css-text-3/#text-indent-property

"Gives the amount of the indent as a percentage of the block container’s own logical width."

The text-indent property's percentage value refers its own block(text's containing block), not its parent element.

jinbeom hong  Sep 29, 2021 
Printed, PDF, ePub, Mobi, , Other Digital Version Page 213
justified text

In justified text, both ends of a line of text are placed at the inner edges of the parent element

->

In justified text, both ends of a line of text are placed at the inner edges of the its element

jinbeom hong  Sep 29, 2021 
PDF Page 238
The text-shadow specification value

The CSS specification has at least one <color> value type while the book uses all <length> value type.

Anonymous  Jul 23, 2020 
268
3rd paragraph

In

Chapter 7 (Basic Visual Formatting) - Section 2 (Altering Element Display) - Subsection (Using auto) - Paragraph 3:

it says:

"In the case where all three properties [margin-left, margin-right and width] are set to something other than auto—or, in CSS terminology, when these formatting properties have been over-constrained—then margin-right is always forced to be auto. This means that if both margins and the width are set to100px, then the user agent will reset the right margin to auto. The right margin’s width will then be set according to the rule that one auto value 'fills in' the distance needed to make the element’s overall width equal that of its containing block."

Unfortunately I couldn't replicate this behavior on any browser. Is this claim still true for newer browsers? I would be happy if you could have a look at it.

Anonymous  Jan 23, 2020 
Printed Page 575
Last paragraph

The following line of text :
"For top-to-bottom languages, writing-mode: horizontal-tb is in effect"

should be replaced by :
"For top-to-bottom languages, writing-mode: vertical-rl is in effect"

The caption beneath figure 12-10 should be :
"The four values of flex-direction property when writing mode is vertical-rl"



Marc Simonis  Nov 03, 2020 
PDF Page 607
Figure 12-36

It says: "The only difference in the CSS between this and Figure 12-35 is the height of the flex container. Here, the flex containers have been reduced to a height of 240 pixels, so as to create flex containers not tall enough to encompass all their flex lines"

But the height of the flex container in Figure 12-36 is exactly enough to encompass all the flex lines. Figure 12-35 and Figure 12-36 is almost the same(12-36 has one more example than 12-35). I suppose 12-36 should replace 12-35, and 12-36 itself should be corrected to what it looks like in the example code files.

Charles  Mar 28, 2020 
PDF Page 628
The last paragraph

The last paragraph says:
In the third example, with no shrink factor, the text doesn’t wrap at all and the flex items overflow the container by quite a bit.

But in the third example, the shrink factor is set to 0 actually. And as the book says, "when omitted in the shorthand flex property value or when both flex and flex-shrink are omitted, the shrink factor defaults to 1", in which the text will wrap to fit the flex container. So to be more accurate, "with no shrink factor" shoule be "with shrink factor set to 0".

Charles  Nov 30, 2020 
Printed Page 630
1st paragraph

The following calculation :

--------------------------
280px + 995px + 480px = 1615px
(0.5 × 280px) + (1 × 995px) + (1 × 480px) = 1235px
X = 1235px ÷ 1615px = 0.7647
--------------------------

should probably be :

--------------------------
280px + 995px + 480px = 1755px
(0.5 × 280px) + (1 × 995px) + (1 × 480px) = 1615px
X = (1755px - 520px) ÷ 1615px = 0.7647
--------------------------



Marc Simonis  Jul 04, 2019 
632
3rd paragraph

This calculation is incorrect:

"Thus, if the browser window is 900 pixels wide, the side columns will each be 175 pixels wide, and the center column 550 pixels wide."

The flex basis for the nav and aside elements is 200px, and for the article element it is 600px (note that the text reads "The main element, on the other hand, has these styles" when it should say "The *article* element, on the other hand ...")

The negative space for a 900 pixel wide window will be 900px - (200px + 600 px + 200px) = -100px, i.e. 100 negative pixels. The shrink factor for the nav and aside are both 1, and for the article it's 2. Thus the shrink factor = -100px/(1*200px + 2*600px + 1*200px) = -1/16 = -6.25%.

So the shrinkage for the nav and aside is 1*(-1/16)*200px = -12.5 px each, and for the article it's 2*(-1/16)*600px = -75px, for a total shrinkage of 2*(-12.5px) + (-75px) = -100px, as expected.

Finally, the nav and the aside will each be 200px - 12.5 px = 187.5 pixels wide (not 175 pixels), and the article (i.e. the center column) will be 600px - 75px = 525 pixels (not 550 pixels).

I tested this out in dev tools, and this is indeed the result when the window is 900 pixels wide.

David Eisner  Aug 07, 2019 
PDF Page 675
Last paragraph


// Quote:
You might assume that the flex: 0 item with the text “flex: 0” in the third and fourth examples will be zero pixels wide, like in the fourth and fifth examples

// Correction
You might assume that the flex: 0 item with the text “flex: 0” in the third and fifth examples will be zero pixels wide, like in the fourth example

Avery Bai  Oct 18, 2021 
PDF Page 689
middle of page

Thus, to place an element into the bottom-right grid cell of a defined grid, regardless of how many columns or rows it might have, you can just say this:
grid-column-start: -1;
grid-row-start: -1;

it should be

grid-column-start: -2;
grid-row-start: -2;

OR

grid-column-end: -1;
grid-row-end: -1;




Kenneth L  Jan 25, 2020 
PDF Page 689
2nd paragraph

#grid {display: grid;
grid-rows: repeat(4, 2em); grid-columns: repeat(5, 5em);}

should be:

#grid {display: grid;
grid-template-rows: repeat(4, 2em); grid-template-columns: repeat(5, 5em);}

Charles  Mar 31, 2020 
PDF Page 690
code piece on top

.three {
grid-row-start: 9;
grid-column-start: col-A -2;}

should be:

.three {
grid-row-start: 4;
grid-column-start: col-A -2;}

Charles  Apr 01, 2020 
Printed Page 690
Last paragraph

This code :

#sidebar { grid-row-start: 2; grid-row-end: 4;
grid-column-start: leftside / span 1;
}

should be replaced by :

#sidebar { grid-row-start: 2; grid-row-end: 4;
grid-column-start: leftside;
}

or maybe :

#sidebar { grid-row-start: 2; grid-row-end: 4;
grid-column-start: span 1;
}

Marc Simonis  Nov 24, 2020 
PDF Page 695
middle of page

.box04 {grid-column: 4; grid-row: span 2 / 5;}
.box05 {grid-column: 5; grid-row: span 4 / 5;}

should be

.box04 {grid-column: 4; grid-row: span 4 / 5;}
.box05 {grid-column: 5; grid-row: span 6 / 5;}



Kenneth L  Jan 26, 2020 
PDF Page 695, 696
The last paragraph, Page 695; The second paragraph, Page 696

It seems that in these two pages, the code, the figure and the relative description don't match each other. The following correction is based on the figure 13-38 on page 695.

______

The last paragraph, Page 695:

box4 is where...It spans back three lines.

should be:

box4 is where...It spans back four lines.

______

The second paragraph, Page 696:

Similarly, box5 ends on line 5, and spans back four lines, which means it starts on row-line –2.

should be:

Similarly, box5 ends on line 5, and spans back six lines, which means it starts on row-line –2.

Charles  Apr 02, 2020 
PDF Page 696
top of page

It seems the specs has changed.

> This happens because spans have to start counting within the explicit grid. Once they start, they can continue on into the implicit grid (as happened with box2), but they cannot start counting within the implicit grid.

should now be

> span counting can start on an implicit or explicit grid line.


Kenneth L  Jan 26, 2020 
PDF Page 714
near bottom of page


quoted:

Values <length> | <percentage>

as the value syntax shows, you can supply only a length for these properties; what it’s less clear about is that the lengths must be non-negative. It’s not possible to supply a percentage, a fractional value via fr, nor a minmax of some sort.

-- end of quote

so it looks like percentage is ok. (and I tried a sample with percentage and it worked).

Kenneth L  Jan 28, 2020 
Printed Page 793
1st paragraph

Probably, this code :
--------------------------
code[type="BASIC"] line::before { counter-increment: linenum }
content: counter(linenum 10) ": ";}
--------------------------

Should be replaced by :
--------------------------
code[type="BASIC"] line::before { counter-increment: linenum 10}
content: counter(linenum) ": ";}
--------------------------

Marc Simonis  Jan 24, 2020 
PDF Page 995
4th paragraph

The 4th paragraph introduces the "not" keyword for media queries. It says:
For example, not (color) and (orientation: landscape) and (min-device-width: 800px) means that...

But in fact, the "not" keyword must be used with a media type, so the example above is not valid syntax. (I tested it in Chrome.) It should be used like: not screen and (color) and blahblah.

This syntax is also mentioned in MDN docs:
https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Using_media_queries#logical_operators

Charles  Jan 19, 2021