Before we split our E-book’s .html file into chapters, let’s run it past the W3C’s Validator.
Okay, okay, terrible joke. But the idea is sound, and important. This is an HTML5 document, styled using a now external CSS2 style sheet. (Someday, maybe, I’ll code the style sheet in CSS3, but don’t hold your breath.) It will become an E-book during Step 5, but for now, it’s a Web page. In fact, you can even go see it live on the Web:
Yellow Buick Review with External CSS
Yellow Buick Review “Apricot” .css file
Before we split this book into chapters, we should check to be sure that our code is correct. You find spelling errors in your documents with a a spell checker, and you find code errors in your E-books with a validator. To do that, you use the World Wide Web Consortium’s (W3C’s) Validation Service. There is a validator built into Adobe Dreamweaver, but all it does is ask the W3C’s Validation Service for an opinion. I’ll get exactly the same information using the Website.
I’ll do three things:
- Test my HTML code against the markup validator.
- Test my CSS code against the CSS validator.
- Fix any real errors that the validators point out. (Just as with spellcheckers, not all errors will be “real.”)
1. Test my HTML code against the markup validator.
Most of the time, I’m going to “Validate by File Upload,” which is the middle option. From there, I can upload an .html file to the server. But for this example, I’ll just give them the link.
Once I do that, the markup validation service will test my file against the rules and standards of the HTML5 specification (it auto-detects which version of HTML a file uses based on information <!doctype> tag and the header file).
It gives me a report, but let’s put that aside for a moment and test the CSS code.
2. Test my CSS code against the CSS validator
Same story here; I go to the CSS validator and either upload my .css file or paste in the link if my file is on the Web. (As an E-book publisher, you might have good business reasons for never wanting to put your own E-book .html and .css files on the Web, but the nice thing about Yellow Buick Review is that we don’t worry about people “stealing” our poetry.)
It auto-detects which version of CSS I’m using. The current standards are CSS2 and CSS3. I’m pretty sure Dreamweaver only supports CSS2, which is okay, because the CSS3 standard is still evolving as of this writing.
3. Fix any real errors that the validators point out.
My HTML came through with (almost) no errors: the HTML5 spec doesn’t like my metadata for Title. The metadata title” is used to provide search engines with a title to display in their search results. (The title you see in at the top of your browser window comes from something else: the <title> </title> tag.) Is this error worth fixing? It would be a problem if I were planning on using this .html file as a Web page, but since it’s going to be an E-book, I think I can safely delete it. Poof! Line 4 is outta here.
<!doctype html> <html> <head> <meta name="Title" content="Yellow Buick Review"> <meta charset="UTF-8">
<!doctype html> <html> <head> <meta charset="UTF-8">
As for my CSS errors?
I committed the same error three times: I defined the amount of text indent for my prose paragraphs as “text-indent: none” instead of the preferred “text-indent: 0 .” Is this worth fixing? Yes. Virtually every Web browser would be smart enough/forgiving enough to understand that when I typed “none” I meant “0.” But E-readers and the EPUB specification are far less forgiving. So yes, I’ll go to lines 164, 174, and 183 to fix the errors (1).
When I make those changes, I’ll want to update the name of my .css file. It will now be “YBReview_Blueberry.css .” I’ll also need to change the HTML in my .html file so that line 6 reads:
<link href="YBReview_Blueberry.css" rel="stylesheet" type="text/css">
Code validation is an important step in the process of making any E-book, poetry or otherwise. Just as you would spell-check your entire manuscript at several points in the editorial process, you should check your code against a validator at several points in the production process. (A final spellcheck never hurt, either.) The spellcheck analogy is even useful in its limitations: a spellcheck tool won’t find every spelling (or grammar) error, and a validator for Web pages won’t catch every E-book error.
We’re about to split out interior .html file into several, smaller .html files. Any code errors that we didn’t catch today might multiply through the smaller files we’re about to create, so it’s good we caught them now.
1. I’m writing these blog posts ex post facto, so I could have fixed that CSS error and left it out of the tutorials. But I thought it better to leave it in so that you could see how to find and fix simple HTML and CSS errors. I hope you don’t feel that I’ve wasted your time.