From an advance review copy for which I thank the publisher.
I’m not sure who wrote this or what they were trying to achieve with it, but frankly it was a mess. Regardless, it's a shame the actual authors didn't get a mention. Anyway, I read this as I typically do, on my iPhone, and the layout was really bad. The contents list occupied no less than sixteen screens and was so poorly laid out that it was useless for any practical purpose. I checked this out on my iPad for comparison and it was only marginally better on that.
The layout of the book itself wasn't much of an improvement, with one topic running into another in a way that was messy and confusing. There seemed to be no overall plan and there was a lot of repetitiveness. I wondered if this was another example of a book being written as a print book, with the ebook version being tossed in either as an afterthought or as nothing more than a means of allowing reviewers such as myself, who don’t merit print versions, to at least see it. If that’s the case, then it did them a disservice because it was a mess and, I assume, poorly represented the print version.
The contents table was a prime example, because it was supposed to be tappable - in that you could tap on a heading and go there, but it had a long series of periods leading from the section title to the page number. Page numbers are irrelevant in an ebook. All you need is the link to tap on, but the links were so close together and so close to the edge of the page that you were more likely to swipe to the next or the previous screen than to go to the chapter heading, or you were equally likely to go to the chapter heading before or after the one you thought you were tapping. It could have been a lot better.
The HTML examples used in the book consisted of the HTML text first, then a green and white divider, and then the HTML as it would be seen on a browser (specifically in this case FireFox 80.0.1). I used 84.0.1 to test some of these examples and ran into issues with them – notably the ‘draggable’ attribute, which simply didn’t work. Other attributes did work. Some of the examples, though, made no sense. At least not to me.
Let me just say at this point that I’m far from an expert HTML coder, but I do use it on my review blog. I don’t go in for anything spectacular or fancy, but I’ve been doing it a long time, so I do have experience and I do understand the principles well. I also have some amateur programming experience in other languages, so I’m far from a newbie at this, but as I said, by no means an expert. I pass this information on just to say that my problems with this are not from a lack of familiarity with this sort of thing.
So when I read this: "HTML attributes values are generally case‐insensitive" and then just a couple of paragraphs later: "In HTML the tag and attribute names are not case‐sensitive but most attribute values are case‐sensitive" that's not my lack of understanding, it’s a direct contradiction! If it had been just one or two things, I would have thought little of it, but I kept on encountering problems of this nature.
For example, I read later, "Now their are some HTML attributes that are called boolean attributes." The word 'their' should be 'there' (there's no there, there! LOL!), but that wasn't the real problem. The problem here was the poor description and the examples. I read, "A boolean attribute when placed in an HTML element represents a true value, and when not placed in an HTML element the boolean attribute represents a false value." If it’s not placed, it’s not an attribute? Well duh! It just seemed pedantic and too wordy.
The book doesn't explain this, but a Boolean value, named after George Boole, is an either-or, a plus or minus, a 'yes' or 'no'. It’s one or the other with nothing in between. It’s the way digital computers work: everything to them is a one or a zero (or technically a low voltage - like four volts - representing the one, or an even lower voltage - 2 volts - representing the zero), but the examples given don't make sense. After several examples of this type: <div itemscope=itEmScOPe>This is a valid HTML boolean attribute. </div>, we get a last one like this: <div itemscope="true">This is NOT a valid HTML boolean attribute. </div>, but this is precisely the same as the others - text within quotes! How is it any different? It’s not made clear what's being said here, and this whole section ends with: "I think you get the point of what is a valid and not a valid boolean attribute from the above example." No, I actually didn’t!
In another example, demonstrating the use of the paragraph elements, the code showed this:
Here is an example of the HTML<p> element below. <p>This is the first paragraph.</p> <p>This is the second paragraph.</p>Which should work fine, but the example output showed this:
This is the first paragraph. This is the second paragraph.Note that there's no paragraphing at all - it’s two sentences in the same paragraph!
Here’s just one more example: <p>The misspelled word <u>pharoah</u> should be spelled pharaoh.</p> This is valid HTML code and should result in the word 'pharoah' being underlined, but the example they showed for the output was this: The misspelled word pharoah should be spelled pharaoh. In other words - no underlining!
It was this kind of problem combined with a seemingly haphazard approach to teaching the reader how to use HTML that turned me off this book and made me DNF it. There is a need for books like this, but this one seemed too scattershot to really teach things in a logical and meaningful way. I think instead of the host of tiny unconnected examples it offered, the book should have oriented itself around creating a whole web page, but doing it in step-wise fashion, each new section of the book focusing on one aspect of HTML, and each adding new things to the overall page, teaching the reader how it all works as it goes.
In that way the reader could have created one page, stored it on their computer, added the new bits to it as they went along, and enjoyed watching the page grow in their browser. In this way they would have created something that worked, and that they could see improve as they went along. They could then later adapt it for their own purposes if they wanted, being confident they knew how it all worked, instead of typing in seemingly random bits of HTML which do only unrelated things, contributing nothing to any organized, overall web page design for the reader, who see zero growing from all their efforts.
But that's just me. I like the step-wise and the logical for books like this, and this one seemed to dissipate too much effort on going every which way without trying to build a coherent whole out of what was being taught. It’s for these reasons that I cannot commend this as a worthy read.
