Errata

The rule reads, "If you really need to define a value, then the same name as the attribute means true while anything else means false;"

This is not correct. Mentioning the attribute makes it true irrelevant of the value you give. CHROME, IE 11 and MOZILLA exhibits this behavior. Even the 2009 version of HTML5 mentions this explicitly here

http://www.w3.org/TR/2009/WD-html5-20090825/infrastructure.html#boolean-attributes

If you find me incorrect please notify via email.

Note from the Author or Editor:
The paragraph "If you really need to define a value, then the same name as the attribute means true while anything else means false;" should say "If you really need to define a value, then the same name as the attribute means true while anything else is invalid;"

I think the images for figure 8-16 and 8-18 need to be switched. figure 8-16 shows app intents as noted in the subtitle for figure 8-18 on page 262.

Note from the Author or Editor:
While the images as they are now are still valid, the reader is right; the images seems to be switched as the captions fit better being swapped. They are talking about the same topic on different situations, that's why they are not really invalid as where they are now.

For a future version, swapping Figures 8-16 and 8-18 (but not the captions) is a good idea.

On page 461 of the 2nd Edition, there is a code sample that illustrates using JavaScript to change the value of the "content" attribute of a meta refresh tag.

The "id" of the given meta tag is "metarefresh", but the code snippet calls the function getElementById("refresh") to retrieve the object.

I believe this is a typo -- "refresh" is the value of the "http-equiv" attribute, but you should use the "id" value of "metarefresh" in your JavaScript code.

Note from the Author or Editor:
On source code page 461, replace:
var mr = document.getElementById("refresh");

with

var mr = document.getElementById("metarefresh");

Starting on page 473 of the 2nd Edition, and continuing to page 474, the author makes confusing statements about the "frequency" of JavaScript timers.
On page 473 the author refers to 10ms as a "low frequency for the timer". However, this is the opposite of what he means. It is a low timeout, but indeed a high frequency.
On page 474 the author talks about low-end devices not accepting "timers with a frequency of less than one second". Again, he probably means "timeout", not "frequency".
Interestingly, in the "bear tracks" sidebar about Gmail at the top of page 475, the author switches the proper usage, referring to low frequency as "1 second or more" and high frequency as "for example, 100ms".

Note from the Author or Editor:
On page 473, replace "If we use a low frequency for the timer" with "if we use a low value for the timeout"

On page 474 replace "don?t even accept timers with a frequency of less than 1 second." with "don?t even accept timers with a timeout value of less than 1 second.